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Introduction 


This manual is intended for use by the System Manager and other users 
who perform the system management functions listed below. 

• Checking device status 

• Checking process status 


• Monitoring system security 

• Scheduling automatic execution of programs 

• Performing initial troubleshooting of hardware and software problems 

• Performing system shutdown/startup 

The manual is organized for ease of reference into several overall parts 
(divider tabs and page headings indicate the part divisions): Introduction, 
Overview, Sll Processes, Data Files, Utilities, System Management Top¬ 
ics, and Appendices. 

If you are new to the System/55 and/or system management in general, 
you may want to begin by reading the sections containing the software and 
hardware overviews, naming conventions, and process descriptions. This 
will provide you with a general picture of the system. Other sections 
provide more detailed information. 


System Organization 

System Integrator's text processing application software and hardware 
run on Tandem Non-Stop processors under the guardian™ Operating 
System. Part of the software and hardware the system uses is produced 
by Sll and part by Tandem. 


The System/55 is organized around the concept of independent logical 
systems running on a single physical system. A physical system is the 
physical hardware configuration (terminals, processors, and so on). A 
logical system is a set of processes (executing programs) that control a set 
of disk files (database). The processes and database make up a logical 
text processing system (for example, Advertising and Editorial). This con¬ 
cept allows groups of users to share the physical resources of the 
System/55 and at the same time provides security through logically sepa¬ 
rate databases. 


Reference Documentation 


The manuals listed below provide more detailed information on some 
topics which can only be covered briefly here. 

• Coyote Editorial User’s Manual (S55-028) 

Provides detailed instruction for using the Coyote vdt and procedures 
for accessing system functions. 





System/55 Editorial Manager’s Manual (sss-oi 0) 

Provides instructions for definition of Sll users and the related baskets 
and desks used in a publishing system. It is useful to all system users 
who have the authority to create, modify, and delete system users, to 
define baskets and desks, and to grant other users access to utility 
processes. 
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• Advertising Management Manual (S55-029) 

Provides documentation covering all aspects of the System/55 advertis¬ 
ing system. This includes information needed for planning, setting up, 
operating, and maintaining the classified system. 

• Device and Font Management (S55-002) 

This covers the major areas of preparation for the implementing of a text 
processing system including the definition of output devices for the 
system, the definition and manipulation of the site’s character set, and 
the organization, loading, testing, and maintenance of typesetting fonts. 

• Report Generation (S55-013) 

Discusses rgen, Sll’s high-level programming language for reporting 
and analysis of data in the System/55, including its data manipulation, 
input/output, and computing capabilities. 

• Form and List Generation (S55-001) 

This manual documents fgen, used to design forms used in the text 
management system for story (take) headers, user, basket, and desk 
profiles, classified ad entry and accounting, font entry, and data for other 
utility processes. It also documents lgen, used to design lists (directo¬ 
ries, indexes) from the structure information created by the Q process. 

• Glossary Definition (S55-027) 

This manual will familiarize you with the procedures for defining glossa¬ 
ries of User Defined Keys (udks), System Defined Keys (sdks), Glos¬ 
sary Defined Keys (gdks) and Locally Defined Keys (ldks) with the 
gloss process. A discussion of the Extended Key (ek) function is also 
included. 

• Input Spooling System Manual (S55-033) 

Documents the processes and procedures necessary to set up and 
maintain the System/55 input spooling system, including instructions for 
setting up automatic review and routing of incoming copy, and format¬ 
ting of both text and tabular material. 

• MAPGEN User’s Manual (S55-032) 

This manual describes how to write and compile mapgen programs. It is 
aimed at persons who have had some experience in programming and 
are reasonably familiar with the System/55 and its terminology. Howev¬ 
er, knowledge of the internal workings of System/55 is not essential. The 
the mapgen language is simple enough to be learned despite minimal 
programming experience. 

Examples are provided throughout the manual to improve its clarity and 
aid in understanding. A comprehensive set of appendices is also includ¬ 
ed for reference purposes. 
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Tandem Publications 

Many Tandem manuals contain information of particular interest to Sys¬ 
tem/55 system management personnel. 

• Introduction to Tandem Computer Systems 

• System Description Manual 

• GUARDIAN Operating System Command Language Utilities Manual 

• System Management Manual 

• System Operations Manual 

• Introduction to Tandem Data Communications 

• EXPAND User’s Manual 
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SECTION 1 

Hardware Overview 

Each System/55 is a unique combination of hardware and software 
components, tailored to meet the needs of each customer site. The basic 
hardware architecture, however, remains the same. Every System/55 in¬ 
cludes the following components: 

• Central Processing Units (crus or Processors) 

• Input/Output Controllers 

• Data Storage Devices (Magnetic Tape and Disk) 

• Editing Terminals 

• Printers and Other Input/Output Devices 

• Operations and Maintenance Console 

This section of the System Manager’s Manual provides an overview of 
the hardware applicable to all System/55 configurations. The “Functional 
Overview” introduces basic concepts; the “Physical Description” explains 
how most of the key components are organized into a mainframe struc¬ 
ture. Each major system component is also described in detail, and a 
typical System/55 is illustrated. 

The configuration of any system is maintained by Sll’s Configuration 
Department. A current configuration drawing package can be obtained 
from that department, and should be kept in the computer room for refer¬ 
ence. 


Functional Overview 

The NonStop Concept (Single-Fault Tolerance) 

The System/55 may be based on any of several versions of the Tandem 
NonStop™ general-purpose computer system. As the name implies, the 
system is designed to continue operating under conditions that would 
disable other systems of similar power. The term “single-fault tolerance” 
most accurately describes how this concept is implemented: each major 
component required for continuous system operation has at least one 
backup of the same type. This redundancy of critical hardware compo¬ 
nents is supported by special software to ensure uninterrupted operation if 
a fault-tolerant component fails. 

Basic System Block Diagram 

Figure 1.1 is a simplified diagram of System/55 components. (A similar 
layout is often used by Tandem and SI I to illustrate actual system configu¬ 
rations.) You may find it helpful to refer to this diagram while reading the 
descriptions that follow. 
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Figure 1.1. System/55 Simplified Block Diagram 
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Central Processing Units (CPUs) 

Three Central Processing Units (opus) are shown near the top. The 
number of cpus in a system varies from a minimum of two to a maximum 
of sixteen. Each cpu can communicate with all other cpus over a shared 
Inter-Processor Bus and with external devices through its own dedicated 
input/output channel, cpus may be any of several types: NonStop I, Non- 
Stop II, or txp. 

Inter-Processor Bus (IPB) 

All cpus in a system are interconnected by an Inter-Processor Bus (ips), 
sometimes known as the Dynabus. The ipb actually comprises two sepa¬ 
rate parallel busses called the x-bus and the Y-bus. Each bus, with a 
maximum data transfer rate of up to 13 megabytes per second, can handle 
all necessary communications between cpus. Both are normally available 
to all cpus. 

Input/Output (I/O) Controllers 

The i/'o channel from each cpu connects to a variety of external devices 
via intelligent i/'o controllers. There are many types of controllers, each 
designed to handle specific peripheral devices (tape drives, disk drives, 
printers, wire-service input lines, terminals, and so on). Some controllers 
are standard Tandem products; others are designed by Sll for specialized 
System/55 applications. 

Nearly all System/55 controllers are dual-ported, that means they can 
be connected to two cpu channels. One cpu owns each controller at any 
given time and handles all i/o through it for the entire system. If any one 
cpu should fail, ownership of its controllers will be taken over by other 

CPUS. 

Peripheral Devices 

As mentioned above, many types of peripheral devices can be connect¬ 
ed and used with the System/55. Some are essential to operation and will 
be found in all systems; others are only used for special purposes. Specific 
devices commonly used with the system will be described in more detail 
later in this section. 

Every System/55 has two types of mass data storage devices: disk 
drives and tape drives. Disk drives store the large amounts of data that 
must be available and quickly retrievable at all times. Tape drives record 
data for safekeeping, long-term storage, or transportation. 

All systems also have a variety of devices to accept input of new data 
and output of processed data. These include wire-service lines, editing 
terminals, personal computers, printers, typesetters, and so on. 

Console 

The general term “console” refers to a special-purpose device found in 
some form on every System, 55. The console provides a central point for 
system operations, management, and maintenance. On some systems the 
console is simply a printer with a keyboard or a video terminal; on other 
systems, a separate sub-system called an Operations and Service Proces¬ 
sor (osp) is used. 
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Support Functions (Power and Cooling) 

All computer systems, of course, must provide power and cooling to the 
components of the system. The System/55 supports its fault-tolerant struc¬ 
ture with redundant power supplies and battery-backup units. If any one dc 
power supply fails, the system and all of its i/o controllers continue to run. If 
power to the entire system is lost, all processors suspend operation, but 
battery power maintains their memory contents for a quick recovery when 
power is restored. 


Physical Description 

The main components of the System/55 are centralized in a mainframe 
of several adjoining cabinets in the computer room. The contents of the 
cabinets are described below and illustrated in Figures 1.2 and 1.3. 

Main CPU Cabinet 

One or more cpu cabinets house the cpus, their i/o controllers, and 
related support equipment. Each cabinet is divided into three sections: 
processor, i/o, and t power and cooling. There are two different cabinet 
types, one for the NonStop I (tns i) processor and another for the NonStop 
II and NonStop txp processors. 


PROCESSOR MODULES 

« 4 max. per CPU Cabinet 

• 16 max. per System 
(4 CPU Cabinets) 

CONTROLLER BOARDS 

• Dual ported 

• Memory Buffered 

• Connect to devices via 
patch panels 


POWER SUPPLIES 

• 1 for each CPU 

• work independently 
of each other 



Figure 1.2. CPU Cabinet. 

The top section of a cpu cabinet holds up to four cpus. There are eight 
circuit board slots for each cpu (some may not be used, depending on the 
type of cpu and amount of memory used). Ribbon cables connect each 
cpu to its front panel, its i/o channel, and the Inter-Processor Bus. 
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The center section of the cabinet provides slots for i/o controller boards. 
Each slot can be connected to the channel ribbon cables of any two CPUS. 
To provide an orderly layout, groups of six or eight slots are usually 
connected to the same pair of cpus— although the exact i/o configuration 
is unique to each system. The NonStop I i/o section is divided into 32 slots; 
the NonStop II and NonStop txp cabinet is divided into 24 slots. 

The bottom section of the cabinet contains cooling fans, an ac power 
distribution box, and DC power supplies for the cpus. 

Tape-Drive Cabinet 

A tape-drive cabinet contains the tape drive that is standard with each 
system. There may be additional (optional) tape drives in other cabinets. 
The bottom of the cabinet supplements the power section of the cpu 
cabinet, providing room for the battery-backup units and additional dc 
power supplies for i/o controllers. The rear of the cabinet is a convenient 
place to mount the patch panels connecting i/o devices to their controllers. 


TAPE DRIVE 

• Provides off-line storage 

• 45 or 125 IPS 

• 800 or 1600 BPI 


POWER SUPPLIES 

• Provide power to 
controller boards 

• Fault tolerant 


BATTERY BACKUPS for 
CPU POWER SUPPLIES 

• 1 per CPU power supply 

• Work independently 
of each other 

Figure 1.3. Tape Drive Cabinet 
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Additional Cabinets 

In larger systems there may not be enough room in the cpu and tape- 
drive cabinets for all of the battery-backup units, power supplies, patch 
panels, and i/o controller boards. One or more additional cabinets may be 
added: 

• i/o-only cabinet for controller boards and power supplies 

• Expansion cabinets for power supplies, battery-backup units, and patch 
panels 

• Patch panel cabinets 
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Processors (CPUs) 

As previously stated, there are three types of Tandem processors: 
Nonstop I, NonStop II, and NonStop txp (abbreviated tns i, tns ii, and 
txp, respectively). Most often a System/55 is configured with all proces¬ 
sors of the same type, but tns ii and txp processors can be combined in 
the same system. With a few exceptions, all three types of processors use 
the same i/o controllers. 

TNS! 

Tandem’s NonStop I, the original design, is a 16-bit, microcode-driven 
processor capable of addressing two megabytes of main memory. The 
tns i has been improved several times and remains a cost-effective alter¬ 
native for many System/55 applications. 

TNS !! 

The second-generation NonStop II is similar in concept, with features 
that give it greater power and flexibility. For example, microcode is “loada¬ 
ble,’’ allowing new micro-instructions to be defined without hardware 
changes, and directly addressable cpu memory is increased to 16 mega¬ 
bytes. 

TXP 

The third-generation NonStop txp has all the features of the tns ii, but 
provides even more speed and power. It executes micro-instructions more 
quickly, using an overlapped instruction “pipeline,” and keeps frequently 
used data in a high-speed cache memory. 

Hard-Disk Subsystem 

Next to the processors, the most important part of the System/55 is the 
hard disk subsystem that stores all software and data used during opera¬ 
tion. The disk drives, like controllers, are “dual-ported.” Just as each 
controller is connected to two opus, each disk drive is connected to two 
controllers. The following paragraphs describe how pairs of opus, disk 
controllers, and disk drives are configured to provide a completely fault-tol¬ 
erant disk subsystem. 

Dual-Controller/Mirrored-Volume Configuration 

As illustrated in Figure 1.4, disk drives on the System/55 are normally 
installed in pairs called “mirrored volumes.” All data is written to both 
drives; therefore, a failure of one drive doesn’t cause the loss of any data 
or interruption of system operation. Each drive is connected to two control¬ 
lers and each controller is connected to two cpus, so there is a total of four 
paths that can be used to access a disk drive. Pairs of controllers normally 
handle one or two mirrored volumes. System operation should continue 
even with the loss of one cpu, one controller, and one disk drive. 

Disk Drives 

Disk drives of several types and storage capacities are used. Two 
general types are used: drives with removable disk packs and drives with 
permanently installed packs. The data storage capacity of each mirrored 
volume ranges from 80 to 675 (gross) megabytes or 64 to 540 megabytes 
(after formatting). 
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Figure 1.4. Typical Systerri'55 Disk and Tape Subsystems 
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Tape Subsystem 

Standard Tape-Drive Configuration 

Every System/55 has one tape-drive controller and one tape drive (Fig- 
,ure 1.4). The standard tape drive is usually one of the Kennedy 9000 
series dual-density models. The controller can, if required, handle one 
additional tape drive. 

Tri-density Tape-Drive Configuration 

* 

An optional tri-density tape drive (not shown in Figure 1.3) is available. 
This tape drive features auto-loading cartridges and can record several 
times as much data per inch of tape. It requires a different controller plus a 
separate formatting unit. One controller and formatting unit can support up 
to four drives. 

High-Speed Line Printer 

Each system usually has at least one high-speed line printer for rapid 
output of proof copy, reports, and so on. A special controller called a 
Universal Interface provides two types of high-speed parallel ports for 
compatibility with a variety of printer models. 

Coyote Terminai/Controiler Configurations 

The system components described up to this point are common on 
nearly every large computer system. For publishing applications, Sll has 
developed its own series of intelligent editing terminals called Coyote 
terminals. These can be connected to any of several Tandem and/or Sll 
controllers. 

Coyote Terminals 

Several Coyote models are available to meet the price and performance 
needs of various users: 

Coyote I—The Coyote I video display terminal (vdt) has an internal 1 6-bit 
microprocessor and 128 k bytes of cpu memory. The user can split 
the display and use each side as a separate logical terminal, or 
alternate between two different full-screen displays. Other features 
include selectable character size, italics, programmed function keys, 
and battery-backup protection. 

Coyote std —The Coyote std is similar to the Coyote I, without some of 
the “luxury” features such as battery backup. It is typically used on the 
System/55-STD (a basic prepackaged version of the system). 

Coyote qb —The Coyote qb is a more powerful version of the Coyote I. It 
has twice the cpu memory, and supports additional features such as 
software-defined keys with on-screen menus. 

Coyote iv—The Coyote iv is a simpler design for applications that do not 
require all of the display features of the above models. It has a fixed 
display format of 80 characters by 24 lines. 

Coyote r— The Coyote r is a special version based on the Coyote iv 
design. It is intended for remote use, with a built-in floppy disk drive to 
facilitate initial downloading of the CPU’s operating program. 
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Controller Configurations 

For maximum flexibility, several Coyote/controller combinations are 
used. The most common configurations are described below. 

Sync—Any Coyote model except the Coyote iv can be configured for 
connection to a Tandem Byte-Synchronous controller (for example, 
through a modem to a remote location). Because each byte-sync 
controller is limited to four devices, only a few terminals are usually 
connected this way. 

tcu —To “multiplex" large numbers of terminals to a single byte-sync line, 
an Sll-designed Terminal Control Unit (tcu) can be used. Several 
tcu versions are available, supporting from nine to fifteen asynchro¬ 
nous Coyotes, plus one or more other asynchronous devices (printer, 
typesetter, and so on). The tcu and its terminals may be located at a 
remote site, with the tcu connected via a modem. Any combination of 
Coyote models can be used with a tcu. (For local terminals, the tcu 
has largely been replaced by the xtm/ftm controller, described be¬ 
low.) 

mtcu —A smaller tcu model called called the Micro Text Control Unit 
(mtcu) is often used at remote sites. It typically controls four Coyote 
terminals (any combination of models) and one or two other asyn¬ 
chronous devices. 

xtm —The Extended Transaction Module (xtm) is an Sll-designed single¬ 
board controller that plugs directly into the i/o section of the Tandem 
CPU cabinet. Each xtm board, like Tandem's controllers, connects 
directly to two Tandem cpus. Any combination of Coyote models, 
sixteen maximum, can be connected to an xtm. Note: There are two 
versions of the xtm, one for use with tns i processors and one 
identified as the xtm ii, for use with tns ii and txp processors. 

ftm— The Fault Tolerant Module (ftm), as the name implies, provides 
fault-tolerant Coyote control similar to the dual-controller disk subsys¬ 
tem. An ftm comprises two controller boards similar to xtms, plus a 
special patch panel. One board is the “primary” at any given time, 
handling all sixteen terminals. If it should fail, the “backup" board can 
take over all communications. Any combination of Coyote models can 
be connected to an ftm. (Note: the ftm cannot be used in tns i 
systems.) 

Asynchronous Devices (other than Coyote Terminals) 

Input and output devices too numerous to detail here can be connected 
to the System/55. Most of them connect to the Sll-designed controllers 
described in the following paragraphs. Sll also makes special patch pan¬ 
els, adapters, and cables for use with the controllers. 

Controllers 

The following controllers plug directly into the i/o section of the Tandem 
cpu cabinet. Each provides sixteen independently programmable i/o lines. 

tpm —The Transaction Processing Module (tpm) is often used to receive 
wire-service input at any standard speed (baud). It can also support 
other serial asynchronous i/o devices, direct or via modems. The tpm 
is not a fully dual-ported controller, but it can be configured to provide 
some degree of fault tolerance. 
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UC)A —The Universal Communications Interface Adapter (ucia) is similar in 
function to the tpm, but it is a fully dual-ported controller. It is also the 
only general-purpose controller than can be connected in a dual¬ 
board fault-tolerant configuration similar to the ftm. 

pcia —The Personal Computer Interface Adapter (pcia) is similar to an 
xtm, but it is tailored for use with several popular personal computers. 

Patch Panels 

Sll makes several types of patch panels for connection of external 

devices to the above controllers. 

Standard—The Standard Patch Panel is used with all single-board config¬ 
urations of Sll controllers (xtm, xtm ii, tpm, ucia, pcia). It supports 
both rs-422 (local) and rs-232 (remote) interface signals. The panel 
is the same size as Tandem’s patch panels. 

Universal—The Universal Patch Panel is used with dual-board configura¬ 
tions of Sll controllers that will have both local and remote devices 
connected (all dual-uciAS and some ftms). One controller board of 
the pair “owns” the patch panel at any given time. The panel is larger 
than other patch panels and requires external power. 

Intelligent—The Intelligent Patch Panel is used only with ftms. It is the 
same size as the Standard Patch Panel, but supports only rs-422 
interface signals (local Coyotes). 


Adapters 

The above controllers and patch panels are for serial communications 
using either rs-232 or rs-422 interface standard. SI! makes external 
adapters that allow connection of devices with other types of interfaces. 

ralph —The Remote Asynchronous Line Peripheral Handler (ralph) is^an 
adapter for conversion of current-loop signals to rs-232 or rs-422, 
rs-232 signals to rs-422 or current-loop, or rs-422 signals to rs-232 
or current-loop. Example: to connect a current-loop printer to a ucia. 

iri—T he Intelligent Remote Interface (iri) is primarily used to connect a 
parallel-interface typesetter to the serial-interface tpm or ucia. The iri 
is a box with plug-in modules that support many popular typesetters. 
Several of these modules can be installed, but only one is selected for 
operation at any given time. 


Network with other Systems 


Each System/55 includes at least one expand™ network line, handled 
by a Tandem synchronous controller. The expand network gives access to 
other Tandem systems (via modem) for messages, data transfer ana so 
on. Customers with more than one System/55 may have dedicated tele¬ 
phone lines permanently connected between systems. Others use dia -up 
lines to establish contact when necessary, such as to Sll for assistance. 


It is also possible, using optional Tandem software, to establish contact 
with non-Tandem systems. 
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Typical System/55 Configuration 


A typical three-processor System/55 is illustrated in the block diagram in 
Figure 1.5. 

DYNA8US 



Figure 1.5. Block Diagram of Typical System 55 (TNS II Processors) 
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SECTION 2 

Software Overview 

« 

The System/55 text processing software runs on Tandem NonStop™ 
processors under the guardian™ Operating System. The system uses 
both Sll and Tandem software. This section of the manual contains infor¬ 
mation on Sll software and database files. 

The System/55 software is organized around the concept of indepen¬ 
dent logical systems running on a single physical system. A physical 
system is the physical hardware configuration (terminals, processors, and 
so on). A logical system is a set of processes (executing programs) that 
control a set of disk files (the database). Together, the processes and 
database make up a logical text processing system (Advertising, Editorial, 
and so on). This concept allows groups of users to share the physical 
resources of the System/55 and at the same time provides security 
through logically separate databases. 

All logical systems are started and supervised by one system-indepen¬ 
dent NonStop process ($zeus) whose task is to coordinate the allocation 
of resources among the users and server processes of each logical sys¬ 
tem. Each logical system's server processes, in turn, are started up and 
supervised by a NonStop overseer process (Scgod, Advertising; Segod, 
Editorial) whose primary task is to interlock records in the database. 
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Major Software Components 

The three components of System/55 software are: 

• guardian Operating System, which contains the programs that run the 
physical devices on the system; 

• Application Programs, which operate the Editorial and Advertising 
systems and make possible the various functions that users may access 
from the vdt; and 

• Utility Programs, which operators and managers initiate to perform spe¬ 
cific tasks as required. 


UTILITIES 

APPLICATIONS 



FILE SYSTEM 

MESSAGE SYSTEM 

I/O DRIVERS 


A-OOG97 


I/O CHANNEL 


GUARDIAN 

OPERATING 

SYSTEM 


Figure 2.2. Major Software Components 


Operating System 

The guardian operating system has three components: 

1. i/o drivers—the interface to the physical devices 

2. Interprocess communications—the interface between processes ($re- 
ceive) 

3. The file management system—the interface to the database that reads 
from, and writes to, program and data files on disk. 

When the operating system is loaded into the CPU it creates one Com¬ 
mand Interpreter, $zooo. This is the Tandem Command Interpreter on the 
osp. From $zooo you can execute two obey files that contain run lines for 
every other process on the system. (See Section 99 for the text of the obey 
files.) 

From the obey files, Szooo creates the application processes. 
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Examples of Application Processes 

$spls —The spooling system supervisor. The spooling system is a set of 
processes that provide an interface between output functions and the 
physical output device. 

Sdna, $dnf— The download process sends to the Coyote all the disk files 
it needs to run (about 9 files). There is a separate download process 
for every ftm. 

Szeus —The supervisor of all the typesetting processes. 

Examples of Utilities 

Utility processes are run by operators and managers. When the process 
is finished, the operator may stop it or the process may stop itself. Each Sll 
(and Tandem) utility is designed to serve a specific function. 

Sll utilities are too numerous to list here. See Appendix B for an index of 
utilities. They are covered in this manual and in other System/55 manuals: 
System/55 Editorial Manager’s Manual, Advertising Manager’s Manual, 
Device and Font Management, Report Generation, Form and List Gener¬ 
ation, Glossary Definition, and Input Spooling System Manual. 

Tandem has many utilities; four of the major utilities are: 

comint —Command interpreter, which is responsible for starting all other 
processes. 

fup —File utility program, which provides data about the status of all files. 
(See Appendix B to locate fup documentation.) 

pup —Peripheral utility program, which governs peripheral equipment. 
(See Appendix B to locate pup documentation.) 

edit— The file editing program, which is used to create the files of system 
commands, such as obey files, (see Appendix B to locate edit docu¬ 
mentation.) 


Processes 

A process is a program that is running or executing. In order for a 
program to run, it must be loaded from the disk into the cpu. A program 
that has been loaded into the cpu and is dynamically executing is known 
as a process. 

Every process that is running in the system has a unique Process 
Identification (pid) number that is assigned to it by the operating system 
when the process is started. Each pid has two parts: 01,069. The first two 
d gits (01) indicate the cpu that is executing the process. The second three 
digits (069 —may be truncated to one or two digits in some displays if there 
are leading zeros) are a randomly assigned process number. 

A process is executed via the run command (see Section 66, 
“run/rund”). These can be executed in four ways: 

1. A manual entry from Sll or Tandem Command Interpreter 

2. Execution of a run line in an obey file 

3. Request from one of the system overseers (Szeus, Segod, Scgod) 

4. Through the Tandem utility spoolcom (only runs spooler processes) 
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Processes may also be given names. Named processes are described 
in Sections 4 through 41. A complete list of named processes is presented 
in Appendix C. 

The processes that control i/o to and from your vdt also have names. 
The name of each vdt process begins with the name of the i/o controller 
followed by the line number. For example, $F506 is the process that 
controls a Coyote on ftm 5 plugged into line or port number 6. 

The vdt also has a device file name that is used when information is 
transmitted to it. Coyote terminals have two file names, one for the left side 
and one for the right side of the terminal. The file names for Coyote vdt 
process $F506 would be Sfs.#L06 and $F5.#R06. et/960 terminals have 
one file name in the following format: $F5.#T06. 

NonStop Processes 

A process can run in one of two modes: 

1. Normal 

2. NonStop—for continuous operation in event of cpu failure 

Most System/55 processes run in normal mode and are restarted by the 
system overseer if they stop. Processes that need to run continuously— 
even in the event of cpu failure—such as textw, which writes data to text 
files, are run in NonStop mode. 

A process running in NonStop mode is really two processes. One pro¬ 
cess is the primary process, which does the work, while the other is the 
backup process which maintains information needed to take over if the 
primary process stops. If the cpu that the primary process is executing in 
fails, the backup process (which runs in a different cpu) takes over. 

NonStop processes must have names. This allows them to be stopped if 
necessary by management personnel. Processes running NonStop have 
two pid numbers (one for the primary; one for the backup) but only one 
name. 

Requestor and Server Processes 

The System/55 processes are divided into two groups: requestor pro¬ 
cesses, and server processes. 

Requestor processes accept requests from vdt users and handle com¬ 
munications between server processes and between other requestor pro¬ 
cesses. 

Server processes do the work sought by a requestor process. Each 
server process is an individual program that performs only one task. 
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Figure 2.3. Requestor and Server Processes 
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SECTION 3 

Naming Conventions 

Sli conforms to the Tandem standard Network Naming Conventions for 
net node, logical devices, permanent disk files, and processes. These 
conventions are explained, and illustrated with examples, below. Familiar¬ 
ize yourself with them before reading further. 

Net Node 

The net node is the the name of a physical hardware configuration. It 
begins with a backslash, followed by 1 alpha character and then up to 3 
alphanumeric characters. 

Syntax Example: 

\ (node name) 

Examples: 

\sn 

System Integrators hardware configuration 

\HTEX 

The Houston Chronicle hardware configuration 

\LAT 

The Los Angeles Times hardware configuration 

Logical Systems 

The logical system name, which is the name of the Sll application 
system, is used when sending messages or transmitting stories to other 
systems. The logical system name contains the net node name without the 
backslash and the single-character system identifier. 

Syntax Example: 

(node nameXsystem identifier) 

Examples: 

SFE 

San Francisco Examiner Editorial System 

SFC 

San Francisco Chronicle Editorial System 

Logical Devices 

A logical device name is the name of the i o process for physical devices 
and also the name of some processes that are treated as devices. 

Each logical device name begins with net node name (default is local 
system if not specified) followed by the device name, which starts with a 
dollar sign, then 1 alpha character and up to 5 alphanumeric characters. 
The device name is separated from the net node name by a period. 

Syntax Example: 

\(node name). S (device name) 
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Examples: 

\LAT. STAPE 

A mag tape drive on the lat system. 

\sn. sdata 

A disk drive on the Sll system. 

$SYSTEM 

A disk drive on the local system. 

$OSP 

The Operations and Service Processor on the local system. 

Logical Devices with More Than One I/O Channel 

Some logical devices have more than 1 i/o channel, port or line. Tan¬ 
dem uses the term “qualified” to specify a particular channel of a device or 
process. 

Follow the standard device name with the first qualifier. If desired, a 
second qualifier can be added. The first qualifier consists of a pound sign 
(#) and up to 7 alphanumeric characters. The second qualifier has no 
pound sign and up to 8 alphanumeric characters. Each part of the logical 
device name is delimited by a period. 

Syntax Examples: 

\(node name). $ (device name).# (qualifier) 

\(node name). S (device name).# (qualifier), (qualifier) 

$ (device name).# (qualifier) 

$ (device name).# (qualifier), (qualifier) 

Examples: 

\HDWR. $F2. #L04 

The left side of a Coyote on ftm Sf 2 on the hdwr system. 

\CLAS. $S. #S. LP 

The location in the collector Ss that points to the line printer on the clas 
system. 

SDATA. #5602 

Name of a temporary disk file on the Sdata volume on the local system. 

SS. #S. SLP 

The location in the collector $s that points to the slow line printer on the 
local system. 

Permanent Disk Files 

Each permanent file on a disk drive has a name. It begins with net node 
name (default is local system if not specified) followed by the name of 
logical device then the subvolume name then the file name. The subvol¬ 
ume is a logical way to group files together and is 1 alpha character then 
up to 7 alphanumeric characters. The file name is 1 alpha character then 
up to 7 alphanumeric characters. Each of the parts of the disk file name is 
delimited by a period. 

Syntax Examples: 

\(node name). S (disk device name), (subvolume name), (file name) 
$(disk device name), (subvolume name), (file name) 
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Examples: 

\TEXT.SDATA3.EDITOR.USERS 

Disk file containing data on Editorial Users on the text system. 


\WP.SSYSTEM.SYSDATA.DEVTABLE 

Disk file containing data on output devices on the wp system. 


\BILT.SDATA.APSFONT.WIDTH 

Disk file containing width data for an aps typesetter on the bilt system. 

SSYSTEM.SYSTEM.MAINT 

Disk file containing object code for maint utility program on the local 
system. 

SDATA.EDITOR.BASKETS 

Disk file containing data for Editorial baskets on local system. 


Process Names 


A process name is the logical name for an executing program. It begins 
with the net node name (default is local system if not specified) then the 
process name, which starts with a dollar sign followed by 1 alpha character 
and up to 3 alphanumeric characters. The net node name is separated 
from the local process name by a period. 


See Appendix C for a list of named processes. 

Syntax Example: 

\(node name). S (process name) 

Examples: 

\SII. SZEUS 


System supervisor process on the SI I system. 


\TEXT. SEPRG 

Editorial purge process on the text system. 


SCAPl 

Advertising aps Output process on the local system. 

SEUPD 

Editorial Header Update process on the local system. 

szooo 

Command Interpreter on local system. 



\ 
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SECTION 4 

Introduction to SI! Processes 

Process Names 

The standard System/55 named processes are described in the sec¬ 
tions that follow. In addition to the pid, processes may also be given 
names, for example Sll calls the System Overseers, which are described 
in Section 6, Segoo and Scgod. Under the standard Sll naming conven¬ 
tions, the names of processes on an Editorial system begin with $e and 
processes on a Advertising system begin with Sc. (See “Naming Conven¬ 
tions,” in Section 3 for a complete description of process-naming conven¬ 
tions; see Appendix C for a list of named processes.) 
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SECTION 5 

SUPER 


Description: Sll Supervisor 

Standard Disk File Name(s) SSYSTEM.Sll.SUPER 

Standard Process Name(s) SZEUS 

Description 

The super process (Szeus) has two major responsibilities: 

1. to create and monitor most processes within the system, resurrecting 

any processes that stop, and 

2. to allocate requestors to servers. 

At system startup, the Szeus process reads through the configuration 
file, which contains process and file description information (see Section 
43 for a description of the configuration file). Szeus creates a process 
corresponding to each process description record except for those records 
describing a system overseer server process (these are ignored). Szeus is 
responsible for maintaining all processes under its control (as defined in 
the configuration file records). 

Szeus is the ancestor of each process that it starts (processes started 
by Szeus are its descendants). Szeus is notified by the operating system if 
one of its descendants stops and is responsible for restarting it. 

To help maintain system balancing, Szeus handles requests from pro¬ 
cesses asking to open a system server process (for example, textr) 
where there may be more than one process capable of handling the 
request. Szeus in turn, makes requests of each suitable process asking 
each how many requestors it is currently handling. 

Based on the replies, Szeus then determines which process has the 
least amount of work to do (that is, the smallest number of requestors) and 
replies to the original request with an actual process id. Requestors can 
then open the system process that was allocated to them by Szeus. 

To create additional processes while the system is operational, make an 
entry in the configuration file describing the new process and make a 
request to Szeus (see Section 85 for a description of the request pro¬ 
cess) to create the process. (Szeus must be the creator of the process so 
that it can monitor the process and restart it if it stops.) 
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PSTAT for SUPER Process 


;pstat $ZEUS 

Process $ZEUS (0,42 & 1,85) was created by: $Z000 
Program file name is SSYSTEM.SII.SUPER2 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 165 and current priority is 165 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 26 bytes 
File 1 is $0 (R/W, S) 

File 3 is $SYSTEM.SYSDATA.CONFIG (R, S) 

Figure 5.1. pstat Information for super Process (Szeus) 


Configuration File Record for SUPER Process 


System _ Record type 0_ Process type 9_ Record #43 

Process Name SZEUS _ 

Program file name SZEUS ___— 

Primary CPU 1_ Alternate CPU 0_ Available CPUs -1 

Priority 165 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class _ Reference name _ 

Home Terminal _ - _ Rund __ 

Input File Name ____ 

Output File Name ____ 

Parameter String ______ 


Figure 5.2. Configuration File Record for super Process (Szeus) 


Run Line Options for SUPER Process 

SUPER supports various run line options to give system managers of 
large systems more control over the order in which Szeus starts process¬ 
es. If the modifier “exactly” is supplied in the run line for super, it will only 
start those vdt processes with a matching server priority. The only modifi¬ 
er will start those vdt processes with a server priority greater than or equal 
to the specified priority. 

The following modifiers can be supplied in super’s run line: 

MODIFIER MEANING 

none Don’t create any vdts 

only n Only create vdts with a server priority > = n 

exactly n Only create vdts with a server priority = n 

delay t Delay t seconds after creating each vdt 

An error message is given if both only and exactly are supplied in the 
parameter string. 
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Run Line Examples 

In obey.strtwarm, the super run line: 

run sii.super /out $0,name Szeus,pri 165,nowait,term $osp/none 

or 

run sii.super /out SO,name Szeus,pri 165.nowait.term Sosp/exactly 3 



REQUEST Functions tor SUPER 


Here is a list of the various requests that can be given to super: 


REQUEST 

il 


ACTION 

Start downed processes (subject to only, delay 
parameters: downed systems) 

Downs Szeus and all processes that are descen¬ 
dants of Szeus on all logical systems on a given 
physical system. 

Downs all processes in the logical system 
Show minimum vdt server priority (see only pa¬ 
rameter) 

Set minimum vdt server priority to n (see only 
parameter) 

Show vdt delay interval (see delay parameter) 

Set vdt delay interval to t (see delay parameter) 
Show required vdt server priority (see exactly pa¬ 
rameter) 

Set required vdt server priority to n (see exactly 
parameter) 


i2,“\node 


i2,“logical system” 
i3 


i3, n 


14 

i4, t 

15 


i5, n 


Setting a minimum vdt server priority (see only parameter) clears any 
required vdt server priority. Similarly, setting a required vdt server priority 
(see exactly parameter) clears any minimum vdt server priority. 
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SECTION 6 

EGOD and CGOD 

Description: System Overseers 

Standard Disk File Name(s) SSYSTEM.Sli.GOD 

Standard Process Name(s) SEGOD, SCGOD 

Description 

Once it has been created, the super process (Szeus) starts a logical 
overseer process for each logical subsystem: Segod for editorial and 
$cgod for advertising. 

The System Overseers are NonStop processes, which serve two major 
functions: 

1. To interlock records used in the editing database 

2. To pass on requests from its requestors to its servers 

Once the system overseers have been started by Szeus, they in turn 
start subordinate server processes and monitor them. For instance, Segod 
creates Seqmj, the process that justifies text to be printed on the qume. If 
Seqmj stops, Segod will restart it. 

An Example 

Each terminal has a terminal control process (vcontrol, see 
“vcontrol”, below) which requests that a function be performed (for ex¬ 
ample, ICMP! Q], justify story or ad) and verifies completion. The system 
overseer process (egod or cgod) locks the side of the terminal from which 
the request was made while the requested process is running. 

Suppose that story #240 is being edited on terminal SF312. The user 
requests justification ( IcmdI PI). The server process for just is Seapj. This 
process will perform the text justification. SF312 is the requestor; Seapj is 
the server. 

The Szeus process is notified that there is a request from Sfsi 2. Szeus 
determines that the request is from the editorial system and notifies 
Segod. Segod passes the request along to Seapj. 

Notice that Szeus becomes a server process, then a requestor to 
Segod, which in turn is both requestor and server. 

The Segod (or Scgod) process keeps a table of all pending requests. If 
the server process stops in mid-job, Segod will not only restart the pro¬ 
cess, it will resubmit the request (for justification in the above example). 

If something in story #240 caused Seapj to stop, it will stop again. If this 
happens twice in less than a minute, Seapj will not be restarted by Segod. 

Record Interlocks 

Record interlocks for a given system are maintained in the system 
overseers' data space. The information kept for each interlocked record 
includes the user name, the function being performed (for example, edit¬ 
ing), where the user is located, and the key to the record. Processes that 
must lock a record in the text database (for example, a story or a user 
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profile) make a request of the system overseer. If the key is not being 
updated or created by any other user on the system, a table entry is made 
describing the interlock and the process making the lock request is given 
an affirmative answer. If the key is in use, the requestor is given a negative 
answer and the lock is not granted. A requestor can only have one data¬ 
base entity locked at any given moment on a particular file number. 

Certain processes (for example, paged, the page dump process) need 
to lock more than one record; these processes open the system overseer 
once for each lock request required. Requestors that lock records are 
responsible for subsequently unlocking those records, thus making them 
available to other users. 

The system overseer also poses as a requestor process (on behalf of its 
requestors) to server processes, which it creates and monitors. Similar to 
$zeus, the system overseer server processes are described in the config¬ 
uration file. At startup time (or on demand) the system overseer (egod or 
cgod) creates all of the server processes described. These server pro¬ 
cesses are grouped in classes; functions are provided to submit a key 
(generally a story number) and a limited amount of data to a server class 
on a “wait for” or “no wait” basis. It is the system overseers' responsibility 
to queue up requests to these server classes and to reply to its requestors 
as services are completed. Server requests are implicitly lock requests 
except that multiple “no wait” server requests can be in effect for a given 
requestor while only one “wait for” request can be in effect. 

The system overseer, like super, is the ancestor of its server processes. 
If one of these processes stops, the system overseer is notified and has 
the choice of either restarting the process or leaving it down. In most 
cases, the process will be restarted. However, if a recently created pro¬ 
cess dies within 60 seconds the system overseer will not restart it. 

PSTAT of EGOD Process 


;pstat SEGOD 

Process SEGOD (1,66 & 0,84) was created by: SZEUS 
Program file name is SSYSTEM.SII.GOD 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 164 and current priority is 164 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 94 bytes 

File 1 is SSYSTEM.SYSDATA.CONFIG (R, S) , last error was 1 
File 2 is $0 (R/W, S) 

File 3 is SSYSTEM.EDITOR.HEADERO (R, S) 

File 4 is SEPRF (R/W, E) 

File 5 is SEDTA (R/W, E) 

File 6 is SESPL (R/W, E) 

File 7 is SESVl (R/W, E) 

File 8 is SEAJ1 (R/W, E) 

File 9 is SEAHl (R/W, E) 

File 10 is SEQUM (R/W, E) 

Figure 6.1. pstat Information for egod Process (partial) 
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File 11 is SEQMJ (R/W, E) 
File 12 is SEQMH (R/W, E) 
File 13 is SEDBO (R/W. E) 
File 14 is SEAP2 (R/W, E) 
File 15 is SEDBJ (R/W. E) 
File 16 is SEDBH (R/W. E) 
File 17 is SEAL (R/W, E) 
File 18 'is SEALH (R/W, E) 
File 19 is SEALJ (R/W, E) 


Figure 6.1. pstat Information for egoo Process (concluded) 


Configuration File Record for EGOD Process 


System E Record type 0_ Process type 1_ Record #55 

Process Name SEGQD _ 

Program file name SSYSTEM.SII. GOD _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs -1 

Priority 164 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class GOD Reference name _ 

Home Terminal __ Rund 

Input File Name __ 

Output File Name ___ 

Parameter String _ 


Figure 6.2. Configuration File Record for egod 



6.3 



















EGOD and CGOD 


Sll Processes 


PSTAT of CGOD Process 


;pstat $CGOD 

Process $CGOD (1,46 & 0,61) was created by: SZEUS 
Program file name is SSYSTEM.SII.GOD 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 164 and current priority is 164 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 94 bytes 
File 1 is SSYSTEM.SYSDATA.CONFIG (R, S) , last error was 1 
File 2 is $0 (R/W, S) 

File 3 is SSYSTEM.CLASS.HEADERO (R, S) 

File 4 is SCPRF (R/W, E) 

File 5 is SCDTA (R/W, E) 

File 6 is SCSVE (R/W, E) 

File 7 is SCAJ1 (R/W, E) 

File 8 is $CSPL (R/W, E) 

File 9 is SCAP1 (R/W, E) 

File 10 is SCAHl (R/W, E) 

File 11 is SCQMJ (R/W, E) 

File 12 is SCQUM (R/W, E) 

File 13 is SCCGJ (R/W, E) 

File 14 is SCCGH (R/W, E) 

File 15 is SCC86 (R/W, E) 

File 16 is SCDBJ (R/W, E) 

File 17 is SCDBO (R/W, E) 

File 18 is SCDBH (R/W, E) _ 

Figure 6.3. pstat Information for cgod Process 


Configuration File Record for CGOD Process 


System C Record type 0_ Process type 1_ Record #69 

Process Name $CGOD _ 

Program file name SSYSTEM.SII.GOD _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs -1 

Priority 164 Alt Priority 0_ Threshold 0_ Server 0— 

Server Class GOD Reference name _ 

Home Terminal ___ Rund _ 

Input File Name ___ 

Output File Name___ 

Parameter String _____ 


Figure 6.4. Configuration File Record for cgod Process 


REQUEST Functions for EGOD 

Listed below are the requests that can be given to egod. 


request 

ii 

i12,i1,(story 
i 14 


ACTION 

Starts downed processes that are descendants of 

EGOD. 

Deletes specified take from requestor’s queue. 
Resets stats obtained by b (busy). 
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REQUEST Functions for CGOD 

Listed below are the requests that can be given to cgod. 

REQUEST ACTION 


il 

Starts downed processes that are descendants of 

i12,i0,d {story #) 
il 4 

CGOD. 

Deletes specified take from requestor’s queue. 
Resets stats obtained by b (busy). 
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SECTION 7 

VCONTROL 

Description: VDT Control Process 

Standard Disk File Name(s): SSYSTEM.SII.ECONTROL 

SSYSTEM.SII.CCONTROL 
Standard Process Name{s): N/A 

Description 

The vcontrol process links the vdt user to the Tandem operating 
system. Ail vdt commands are acted on by this process. For example, the 
vcontrol process prompts the user for additional information and dis¬ 
plays the results of each command. 

The virtual text scrolling is implemented through vcontrol, which 
keeps track of text that is no longer in vdt memory and passes text back to 
the vdt on demand. 

The save strings and each user’s move area are also maintained by 

VCONTROL. 

vcontrol provides for the interactive mode of a Command Interpreter. 

A vcontrol process is run against each operational vdt in the system 
(via super). There are two versions of vcontrol: econtrol for the 
Editorial system, and ccontrol for the Advertising system. 

vcontrol makes requests of the system overseer to lock records as the 
user demands and makes requests of the system overseer server pro¬ 
cesses (for example just) for processing user requests involving these 
peripheral processes. 

vcontrol interacts directly with msg to broadcast and receive user 
messages; with vputget to format and validate database records so that 
they can be displayed on the vdt; with textr to read from the text file, and 
with textw to write to the text file and updateh to write to the story header 
file. 

When a user presses (cmd| to sign on, vcontrol reads through the 
configuration file, opening the various data files and asking zeus for the 
specific names of various processes it must communicate with. If the user 
name is found in the user file and the correct password has been entered, 
vcontrol informs other processes that the user has signed on to that 
terminal. 

When a user requests to edit a story, vcontrol asks the system 
overseer to allocate the story to it exclusively. If it is not currently allocated 
to someone else, the lock is granted, vcontrol reads the story header 
and makes a request of the form processor (vputget) to format the header 
and return the form text. This form text is then written to the terminal. 

As the vdt makes virtual requests for text (the user activates text rolling 
or scrolling functions), vcontrol makes requests of textr for text file 
records or reads them from the text holding area, passing the text file 
records to the vdt intact. As vdt memory fills and text needs to be 
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unloaded to make room, the text is sent to vcontrol, which records the 
data in the text holding area. 

When a story is finished (implied by the user going on to something 
else) the header is retrieved from the terminal and passed again to vput- 
get to interpret and perform syntax checks. If the syntax checks are 
passed, the binary header record is returned and vcontrol either pro¬ 
ceeds to format text file records and write them to the text file using the text 
write process (textw) or it submits a background save request to the 
system overseer, which causes a save process to store the changed text 
in the text file independent of subsequent events on the vdt. 

If the text is saved by vcontrol itself, when all the text is written the 
new story header is saved in the header file (using updateh) and 
vcontrol informs the system overseer that the story is no longer in use. 
Similar events occur when the background save process handies the 
request. Short stories or stories filed using IcmdI fwl are saved by 
vcontrol itself; all other save requests use the background save process. 

PSTAT of ECONTROL Process 


;pstat $F505 

Process SF505 (1,96) was created by: $ZEUS 
Program file name is SDATA.SII.ECONTROL 
Creation ID = 254,255 and process ID = 255,255 
Creator may stop process, and no one has tried. 

Initial priority was 140 and current priority is 140 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 2048 bytes 
File 1 is $DATA.EDITOR.MSGFILE (R/W, S) 

File 2 is SF5. #L05 (R/W, S) 

File 3 is $F5. #R05 (R/W, E) 

Request 1 is WRITEUPDATE for 0 bytes 
File 4 is SEFIO (R/W, S) 

File 5 is SEVPM (R/W, S) 

File 6 is SEGOD (R/W, S) 

File 7 is SEGOD (R/W, S) 

File 8 is SEMSG (R/W, S) 

File 9 is SEVPT (R/W, S) 

File 10 is $EVGT (R/W, S) 

File 11 is SEFIL (R/W, S) 

File 12 is SETRl (R/W, S) 

File 13 is SEUPD (R/W, S) 

File 14 is SDATA.EDITOR.HEADER (R/W, S) 

File 15 is SDATA.EDITOR.STRINGS (R/W, S) 

File 16 is SDATA.EDITOR.XBASKET (R/W, S) 

File 17 is SDATA.VPEND.F505 (R/W, P) 

File 18 is SDATA.EDITOR.MSGFILE (R/W, S) 

Figure 7.1. pstat Information for an econtrol Process ($F505) 
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Configuration File Record 
for an ECONTROL Process 


System E Record type 0_ Process type 4_ Record #125 

Process Name $F505 _ 

Program file name SSYSTEM.SII.ECONTROL _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs 0_ 

Priority 140 Alt Priority 0_ Threshold 0_ Server 0__ 

Server Class _ Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name SF5. #LQ5 _ 

Parameter String E;SSYSTEM.VPEND.F505; ; ; SF5. #R05 _ 


Figure 7.2. Configuration File Record for econtrol Process ($F505) 


REQUEST Functions for VCONTROL 

Listed below are the requests that can be given to vcontrol. 

REQUEST ACTION 

-20 Start the terminal. This request can be made to any 

econtrol process. 
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SECTION 8 

AOPR 

Description: Application Operator Logging Process 
Standard Disk File Name(s): SSYSTEM.SYSTEM.AOPR 
Standard Process Name(s): SAOPR 

Description 

aopr (Application Operator Logging Process) is a process that receives 
operator messages and writes them to the console and a log file. Mes¬ 
sages are held in the log file until it becomes full, when the oldest mes¬ 
sages are over written by new messages. Normally, aopr is started at 
system cold-start or warm-start from an obey file (see strtaopr obey file, 
Section 99). 

The aopr process's relationship to other System/55 processes is illus¬ 
trated in Figure 8.1. 




Figure 8.1 . The aopr Process 
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The console message-logging process is called $o. Sreceive handles 
all interprocess communication and forwards Sll and Tandem system 
messages to $o, which writes the messages to the console, a disk file 
(SSYSTEM.SYSTEM.OPRLOG) and tO $AOPR. 

The aopr process writes the messages to another system disk file 
(Ssystem.system.aoprlog) and to a different system console (if de¬ 
sired). Most systems are configured to have aopr write all messages— Sll 
and Tandem—to the aoprlog file. Because aopr also controls the mes¬ 
sage file, it may direct Tandem system messages to any terminal on the 
system. (See “Message Groups or Operator Messages” later in this sec¬ 
tion.) 

The $o process is controlled with the “pup console" command (see 
Tandem Peripheral Utilities Manual for a complete description of pup). 
This command performs two independent operations: 

1. It can respecify the console operator listing device. The default is the 
first type 6, subtype 32 hardcopy printer it can find in the device listing 
(pup listdev). 

2. It can switch the log file and allow the user to decline to have any 
recorded; however, shutting off logging-to-disk of messages may also 
prevent messages from reaching the console. It is advisable to keep 
both up; console messages are often used in system error analysis. 

PSTAT of AOPR Process 


;pstat $aopr 

Process $AOPR (2,27 & 3,10) was created by: $ZOOO 
Program file name is SSYSTEM.SYSTEM. AOPR 
Creation ID = 255,255 and process ID = 255,255 
Creator may stop process, and no one has tried. 

Initial priority was 190 and current priority is 190 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 200 bytes 
File 1 is SOSP (R/W, S) 

File 2 is SSYSTEM.SYSTEM.AOPRLOG (R/W, S), disk address = 171009 
File 3 is SOSP (R/W, S) 

Figure 8.2. pstat Information for aopr Process (Saopr) 


AOPR Run Command 

The aopr run command may be entered in the following format from the 
Sll Command Interpreter or from an obey file (see strtaopr obey file, 
Section 99). 

aopr/ name SAOPR, out {outfile name), nowait/(logical system name) 


name (process name)—The name given the process (must be $aopr). 

out (out file name)—The name of the file where Saopr messages will be 
logged. 

nowait —Specifies that the Command Interpreter prompt be returned 
without waiting for the Saopr process to complete. 
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(logical system name)—The system for which operator messages will be 
gathered (for example, she). 


A typical aopr run command might be entered as shown below: 

;aopr/ name $appr ,out gpsp^ term Sosp^ npwait/siie 


Writing Console Data to Multiple VDTs 

aopr can be used to write the console data to more than one vdt. When 
aopr is started it uses its out file as the “permanent" vdt. You can use 
request to open and close other “temporary” vdts, as illustrated in Figure 
8.3. 


;request Saopr 

00,102; ? il, Sterm4 open Sterm 4 as vdt #i 
00,102; ? il close vdt #1 

00,102; ? i4, Sf 2. #13 open Sf2.#li 3 as VDT #4 
00, 102 ; ? i4 close VDT #4 

Figure 8.3. Opening and Closing Temporary vdts for aopr Messages 


The parameter n indicates that the command applies to vdt #i;i2 
indicates vdt # 2 , and so on. Four vdt logs are supported in addition to the 
permanent vdt (which cannot be altered using these requests). “Tempo¬ 
rary” as used here means only that the vdt can be closed using request. 

aopr tells its backup process about the temporary vdts and will contin¬ 
ue to send a copy of the console log to these vdts after a backup takeover 
just as it does for the permanent vdt. 


Listing AOPR Messages 

The aopr log file has three paths that may be used when listing mes¬ 
sages on your vdt: 


1. DT,the date on which the message was logged; 

2. TX:the first 10 characters in the message, and 

3. FR:the network node ,cpu number,and process id number. 

To list all aopr messages currently held in the file,enter iCMDifx] and 
complete the prompt by entering aopr log in the list name field and 
press (return! . 

List Name aopr log Path _ Proof _ Filter by _ 

key _ 


A portion of the resulting list is illustrated in Figure 8.4. The list begins 
with the oldest message currently held in the file. 


AOPR log file 


12/08/82 

9: 26 

Mss Date 

Time 

From 

Text 



15 02DEC 

GING ON 

12: 00 

001.00,003 

LOG TERMINAL LDEV # 0003, 

DISK 

LOG- 

15 02DEC 
GING ON 

12: 00 

001.00,003 

LOG TERMINAL LDEV # 0012, 

DISK 

LOG- 

02DEC 

301 

02DEC 

02DEC 

12: 04 

12: 13 

12: 13 

001.00.026 

001.00,011 
001.00.011 

SDNC: I/O failed SA5. #T00: 

NO RESPONSE FROM SCO 

GOOD SESSION ON SCO 

error 


Figure 8.4. aopr Log Listing: No Path or Key 
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The width of the list is defined with lgen. To read t he co mplete entry, 
point the cursor to the desired entry in the list and press |cmd| [f]. 


Path “DT”: Date 

Path dt allows you to list the aopr log entries that occurred after a 
specified date and time. Complete the fcrTol 0 prompt by entering list 
aopr log, path dt and specifying the date and time at which you want the 
listing to begin (December 8 12:40 in Figure 8.4). The date and time in the 
key field must be entered just as it would appear in the aopr log listing (no 
spaces). The month must be entered in uppercase. 

List Name aopr log Path dt Proof _ Filter by _ 

Key 08DEC8412: 40 ___ 

The resulting list is illustrated in Figure 8.5. The list begins with the first 
message logged on the date specified. 


AOPR log file (DT, 08DEC) 


12/08/82 9:26 


Msg Date Time 


63 08DEC 12:44 
ERROR #219 

7 08DEC 12:44 
08DEC 12:44 
08DEC 12:44 


From _ Text 

001,02,012 LDEV 0003 CU %170 II0/HII0 I/O BUS 

001,02,012 LDEV 0033 CU %170 DOWN 

001,02,026 $DNC; I/O failed $C0.#T00: error 66 

001,00,066 $C001; File $C0. S#L01: error 66 


Figure 8.5. aopr Log Listing for December 8 


Path “TX”: Message Text 

Path tx allows you to list the aopr log entries by message text. Com¬ 
plete the IcmdI 0 prompt by entering list aopr log, path tx. In the key 
field, you may specify up to 10 characters of the text messages you wish 
listed. The message text in the key field must be entered just as it would 
appear in the aopr log listing. 

This path allows you to list all the messages about a particular process 
($zeus in the example below). 

List Name aopr log Path tx Proof _ Filter by _ 

Key SZEUS __ 

The resulting list is illustrated in Figure 8.6. 


AOPR log file (TX, SZEUS) 


Msg Date Time 
04DEC 10:55 
04DEC 15:00 
07DEC 20:33 
20DEC 13:53 


From _ Text 

001,02,027 SZEUS 
001,02,043 SZEUS 
001,01,034 SZEUS 
001,02,033 SZEUS 


12/08/82 9:26 


BACKUP created 
BACKUP created 
BACKUP created 

Can't send STARTUP message to 


Figure 8.6. aopr Log Listing for Path tx, Key Szeus 


Path “FR”: From 

Path fr allows you to list the aopr log entries by network node, cpu 
number, and process id number. Complete the Icmdi 0 prompt by enter¬ 
ing list aopr log, path fr. Entries in the key field will be ignored. 

List Name aopr log Path fr Proof __ Filter by _ 

Key ___ 

The resulting list is illustrated in Figure 8.7. 
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Messages are listed in ascending order by network node and cpu 
number. 


AOPR log file (FR) 
Msg Date Time 


04DEC 11:00 
04DEC 11:00 
08DEC 09:00 
08DEC 09:00 
02DEC 13:00 
OTDEC 18:00 


From _ Text 

001,00.075 SA304 
001.00,060 SSCHD 
001.01,034 SZEUS 
001,01,033 SZEUS 
001,02,033 SZEUS 


12/08/82 9:26 

Can't open $A3.#T04, Entry in 
Backup process running 
Can't create SEMON: error 11 
Descendant abended SPOOl 
Descendant abended SSEND 


001.02.017 LDEV 0038 I/O BUS ERROR #218 


Figure 8.7. aopr Log Listing by Path fr 


Sample AOPR LOG Entries 

The examples below illustrate aopr log entries for typical system occur¬ 
rences. 

The aopr log entry in Figure 8.8 indicates that a user has made at least 
three attempts to sign on to the system. Note that the terminal number is 
given (Sfios). 


06AUG84 

08: 58 

003.01.055 

Someone trying to sign on to 'SF1.#L05 WELCOME TO DEMO' (BALDRID 




Figure 8.8. aopr Log Entry for Unsuccessful Sign-on 



In Figure 8.9, the qume process (Sequm) is unable to print the story that 


has been sent to it. 


06AUG84 

09: 27 

003.01.033 

SEQUM; 

Recode table is bad (story #1574) 




Figure 8.9. aopr Log Entry for qume Print Process Failure 



Figure 8.10 

illustrates entries logged as a successful coldstart com- 


pletes. 



06AUG84 

13: 21 

003.01.003 15 LOG TERMINAL LDEV # 0000. DISC LOGGING ON 

06AUG84 

13: 21 

003,01.024 

SDNF1 

BACKUP created 

06AUG84 

13: 21 

003.02.016 

SDNF2 

BACKUP created 

06AUG84 

13: 21 

003,03.011 

SDNF3 

BACKUP created 

06AUG84 

13: 25 

003,03.014 

SETW; 

Backup process created 

06AUG84 

13: 25 

003.03.016 

SCTW; 

Backup process created 

06AUG84 

13:25 

003,03.014 

SETW; 

Text file is filling up on SSYSTEM.EDITOR.TEXTF 

06AUG84 

13: 25 

003.01.031 

SCTR: 

Ready 

06AUG84 

13: 25 

003.03.019 

SETR1 

Ready 

06AUG84 

13: 26 

003.02.020 

SEG0D 

Backup created 

06AUG84 

13: 26 

003.02.021 

SCG0D 

Backup created 

06AUG84 

13: 26 

003.03.021 

SCMSG 

Backup process running 

06AUG84 

13: 27 

003.02.032 

SEFI0 

Backup created 




Figure 

8.10. aopr Log Entries for Successful Coldstart 



The entries in Figure 8.11 indicate that the network node was not found: 


the net was not up. 


06AUG84 

13: 42 

003.03.045 

SSOSP 

Device not supported by SII ?°.SX1.#R00 

06AUG84 

13: 42 

003.03.045 

SHOSP 

Device not supported by SII ??.SX1.#R11 

06AUG84 

13: 42 

003.03.039 

SHCLR 

Device not supported by SII ??. SX1. #R00 


Figure 8.11. aopr Log Entries for Network Node not Found 
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In Figure 8.12 a terminal process ($F2io) has been stopped twice in one 
minute. Szeus is unable to restart the process. Notice that error 201 was 
logged (current path to the device is down or an attempt was made to write 
to a non-existent process). 


06AUG84 10:15 003,00,014 SZEUS; 

06AUG84 10:19 003,00,014 SZEUS; 

06AUG84 10:19 003,00,014 SZEUS; 

06AUG84 10:19 003,00,014 SZEUS; 

06AUG84 10:19 003,00,014 SZEUS; 


Descendant stopped SF210 
Descendant stopped SF210 
OPEN failed for SF210 error 201 
Descendant stopped SF210 
Failed to run process SF210 


Figure 8.12. aopr Log Entry for a Process Stopped Twice Within One Minute 


The sequence of entries in Figure 8.13 shows downed network lines 
(error 248: network line handler error, operation aborted) coming up. This 
indicates that the “other" (remote) is not responding or is not connected. 


06AUG84 

14: 11 

003,02,004 

6 

LDEV 

0026 

UP 





06AUG84 

14: 11 

003,01,004 

45 

LDEV 

0026 

NET: 

LINE 

NOT READY, 

ERROR 

#248 

06AUG84 

14: 11 

003,01,004 

44 

LDEV 

0026 

NET: 

LINE 

READY 



06AUG84 

14: 12 

003,02,005 

6 

LDEV 

0027 

UP 





06AUG84 

14: 12 

003,01,004 

45 

LDEV 

0027 

NET: 

LINE 

NOT READY, 

ERROR 

#248 

06AUG84 

14: 12 

003,01,004 

44 

LDEV 

0027 

NET: 

LINE 

READY 



06AUG84 

14: 12 

003,02,006 

6 

LDEV 

0028 

UP 





06AUG84 

14: 12 

003,01,004 

45 

LDEV 

0028 

NET: 

LINE 

NOT READY, 

ERROR 

#248 

06AUG84 

14: 12 

003,01,004 

44 

LDEV 

0028 

NET: 

LINE 

READY 




Figure 8.13. aopr Log Entries for Network Lines Coming Up 


The lines from the aopr log in Figure 8.14 detail a failed attempt to 
restart a terminal. The message “Entry in use” indicates that a command 
interpreter or other utility is running on the right side of terminal $F3i 0. 

07AUG84 15:13 003,00,017 SZEUS; Descendant stopped SF310 

07AUG84 15:13 003,02,043 SF310; Can't open SF3.#R10, Entry in use 

Figure 8.14. aopr Log Entry for Failed Terminal Restart 

In Figure 8.15, a request to proof a story failed because device Show- 
ard does not exist (error 14). 


07AUG84 15:13 003,03,008 SEPRF: Cannot open SHOWARD: error 14 

07AUG84 15:13 003,02,020 SEGOD; I/O error to server SEPRF error 53 

07AUG84 15:13 003,02,020 SEGOD; Lost a request to PROOF error 53 Story '#5130' 

Figure 8.15. aopr Log Entries for Failed Proof Request: Nonexistent Device 

In Figure 8.16, a request to proof a story failed because the file was not 
found or the record was not found in the file Ssystem.system.scott (error 
11 ). 


07AUG84 15:23 003,03,008 SEPRF; Cannot open SSYSTEM.SYSTEM.SCOTT: error 11 

07AUG84 15:23 003,02,020 SEGOD: I/O error to server SEPRF error 53 

07AUG84 15:23 003,02.020 SEGOD: Lost a request to PROOF error 53 Story ’#2350' 

Figure 8.16. aopr Log Entries for Failed Proof Request: Record not in File 
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Figure 8.17 illustrates entries for devices that have gone off line (error 
111) or were taken off line (error 66). 


07AUG84 16:26 003,02.018 SSPLS DEV SQUME1 OFFLINE, ERROR: 111 

07AUG84 16:42 003,02,018 SSPLS DEV SSLP OFFLINE, ERROR: 066 


Figure 8.17. aopr Log Entries for Devices Offline 


The entries in Figure 8.18 were produced because a schedset program 
specified So as the output terminal. 


07AUG84 17:12 003,03.069 
07AUG84 17:12 003,03,069 
07AUG84 17:12 003,03,069 
07AUG84 17:12 003,03,069 
07AUG84 17:12 003,03,069 
07AUG84 3.7:12 003,03,069 
07AUG84 17:14 003,03,069 
07AUG84 17:14 003,03,069 
07AUG84 17:14 003,03,069 
07AUG84 17:14 003,03.069 
07AUG84 17:14 003,03.069 


Users and Items in use for 1803 Editorial System 
LOUISE (SF203) is reading Story '#11511' 

DEB (SF214) is updating Story 'HJ' 

DEBBIE (SF215) is updating Story 'std defaults' 
SHARON (SF107) is creating Story '#4752' 

4 busy item(s) 

Users and Items in use for 1803 Classified 
CUPDATEH (SCUPD) 

RCVR (SCRCVi 

2 signed on user(s); No busy item(s) 


Figure 8.18. aopr Log Entries Created by schedset Program 


The entry in Figure 8.19 indicates that there is no record michael in the 
file Ssystem.editor.proofkey (error 11: file not in directory or record not 
in file). The editorial proof process is (Seprf) indicating that it cannot i/o to 
a file that doesn't exist. 


07AUG84 20:28 003,03,008 SEPRF; I/O failed: MICHAEL in SSYSTEM.EDITOR.PROOFKEY: error 11 


Figure 8.19. aopr Log Entry 


for Proof Process Failure 


Message Groups for Operator Messages 

If a message notification file entry exists, selected system messages 
can be sent to specific message groups. In order to do this you must first 
create a message group to which you want the messages sent. Display a 
list of groups ( fcMDl fxI for list groups— no path o r key required). Position 
the cursor at a record in the list and execute 1cmd| Q [F] to copy the form. A 
blank form is displayed as illustrated in Figure 8.20. 


Copying record 

Group name __ User name _ 

System _ 

Figure 8.20. Form for Message Group Definition 


Complete the form as described below and illustrated in Figure 8.21. 
The message group you create may have as many members as neces¬ 
sary. 

GROUP NAME— The name of the message group you wish to create (for 
example, aopr group). 


USER NAME— The name of the user who is to be a member of this group, 
and to whom you wish messages to be sent. 
system — If the user to whom the messages are to be sent is on another 
logical system, you must specify the system name here. 
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Copying record 

Group name AOPR GROUP User name RICK _ System 


Figure 8.21. Completed Message Group Definition Form 

Once you have created a group to which messages may be sent, you 
must determine which messages should be sent to the group members. 
Call up a list of the message notification file ( IcmoI IxI. list aopr groups). 
A typical list is illustrated in Figure 8.22. 


Operator 

message 

alert groups 

12/08/82 13:46 

Message 

Group 

Description 


1 


Unexpected mount 


2 


Can't access label 


3 


I/O bus error 


4 


Device error 


5 


I/O retry 


6 


Device up 


7 


Device down 



Figure 8.22. List of Message Notification Groups 


To specify that a message is to be sent to the message notific ation 
group, position the cursor at the desired message and enter IcmdI [f] to 
edit the form. When the form is displayed, enter the name of the group to 
which the message is to be sent (Figure 8.23). 


Editing record 

Message 6_ Group AOPR GROUP 

Description Device up _ 

Figure 8.23. Completed Message Notification Form 

In Figure 8.24, two messages have been selected for transmission to 
aopr group. Whenever these message are logged, they will be displayed 
on the vdts of the members of the group. 


Operator 

message alert 

, groups 

12/08/82 13:46 

Message 

Group 

Description 


1 


Unexpected mount 


2 


Can't access label 


3 


I/O bus error 


4 


Device error 


5 


I/O retry 


6 

AOPR GROUP 

Device up 


7 

AOPR GROUP 

Device down 



Figure 8.24. List of Message Notification Groups 



REQUEST Functions for AOPR 


Here is a list of the various requests that can be given to aopr: 

REQUEST ACTION 


i1,”$term4" 

il 

iy, ”$xxx” 


opens $term4 as console log device #1 
closes log device #1 

opens $xxx as console log device #y (possible y 
values from 1 to 4) 
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AOPR Error Messages 

The following messages may be given while you are using aopr. Most 

messages occur immediately following the command entry that generated 

the error. 

“Backup cpu failure”— aopr’s backup abended in a cpu failure. 

“Backup open failed for”—The process can't talk to backup. 

“Backup process running”—This is intended as information only. 

“Backup stopped or abended”—The backup process has been stopped or 
has abended for some reason. 

“case statement index ouf of range”—Contact your Sll System Engineer. 

“checkopen can't talk to backup”—The backup has probably abended. 

“checkpoint can't talk to backup”—The backup has probably abended. 

“Fatal i/o error in”—There has been a hardware failure, the disk drive is 
not working properly, the file is full, etc. 

“High priority write failed”—Contact your Sll System Engineer. 

“I must have a process name”—Either the file does not exist or you do not 
have the authority to access it. 

“Primary cpu failure”—The primary process abended in a cpu failure. 

“Primary process abended”—The primary process has abended for some 
reason. 

“Primary process died before checkpointing”— Someone has stopped 
the primary process. 

“Primary process stopped”—The primary process has stopped for some 
reason. 
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SECTION 9 

APS 


Description: APS Driver 

Standard Disk File Name(s): SSYSTEM.SII.APS 

Standard Process Name(s): SEAPI, SCAP1 

Description 

aps is a system overseer server process that outputs data to drive 
Autologic phototypesetters, aps uses textr to read from the text file and 
spools its output to the designated spooling location using standard Tan¬ 
dem spooling procedures. Complete information for configuring this pro¬ 
cess can be found in Device and Font Management (S55-002). 

PSTAT of Editorial APS Process 


;pstat $EAP 

Process $EAP (1,80) was created by: SEGOD 
Program file name is SSYSTEM.SII.APS 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 90 and current priority is 90 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 806 bytes 
File 1 is SO (R/W, S) 

File 2 is SSYSTEM.APS.WIDTH (R, S) 

File 3 is SDATA.EDITOR.HEADER (R/W, S) 

File 5 is SEVPT (R/W. S) 

File 6 is SEUPD (R/W, S) 

File 7 is SSYSTEM.EDITOR.0UTL0G (R/W, S) 

File 8 is SETRl (R/W, S) 

Figure 9.1. pstat Information for aps Process (Seapi ) 


Configuration File Record for APS Process 


System E Record type 0_ 
Process Name SEAPI _ 


Process type 3_ Record #60 


Program file name S SYSTEM. SI I. APS _ ... 

Primary CPU 1_ Alternate CPU 0_ Available CPUs p_ 

Priority 90 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class APS Reference name 

Home Terminal __ 

Input File Name __ 

Output File Name _ 

Parameter String 


Rund 


1 = sile: 5 = S' 


Figure 9.2. Configuration File Record for Editorial aps Process (Seapi) 
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PSTAT of Advertising APS Process 


;pstat $CAP1 

Process $CAP1 (1,58) was created by: $CGOD 
Program file name is $SYSTEM.SII.APS 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 90 and current priority is 90 

LISTEN LCB's reserved: 0, LINK LCB's reserved: 0 
LISTEN LCB’s in use: 0, LINK LCB's in use: 0 
I/O was last done to file 1, last error was 40 
File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 806 bytes 
File 1 is $0 (R/W, S) 

File 2 is $SYSTEM.APS.WIDTH (R, S) 

File 3 is $SYSTEM.CLASS.HEADER (R/W, S) 

File 5 is SCVGT (R/W, S) 

File 6 is $CUPD (R/W, S) 

File 7 is $SYSTEM.CLASS.OUTLOG (R/W, S) 

File 8 is $CTR (R/W, S) 

Figure 9.3. pstat Information for Advertising aps Process (Scapi ) 


\ 


9.2 





Sll Processes 


BATCHER 


~ SECTION 10 

BATCHER 

Description: Batch Process 

Standard Disk File Name(s): SSYSTEM.Sll.BATCHER 
Standard Process Name(s): SEBAT 

% 

Description 

The purpose of batch is to process batches of stories sent to it by 
vcontrol. Depending on the function supplied with the batch, the stories 
may be output, transferred* spiked, or proofed. 

PSTAT of BATCHER Process 


;pstat SEBAT * 

Process SEBAT (0,80) was created by: SZEUS 
Program file name is SSYSTEM.SII.BATCHER 
Creation ID = 254.255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 100 and current priority is 100 

I/O was last done to file 5, last error was 1 
File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 262 bytes 
File 1 is SO (R/W, S) 

File 4 is SDATA.EDITOR.HEADER (R/W, S) 

File 5 is SSYSTEM. EDITOR.BATCHQ (R/W, S), last error was 1 
File 7 is SEMSG (R/W, S) 

File 8 is SETR1 (R/W, S) 

File 9 is SEUPD (R/W, S) 


Figure 10.1. pstat Information for batcher Process (Sebat) 


Configuration File Record for BATCHER Process 


System E Record type 0_ Process type 36 Record #343 

Process Name SEBAT _ 

Program file name SSYSTEM.SII.BATCHER _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs 0_ 

Priority 100 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class BATCH Reference name _ 

Home Terminal ___ . Rund _ 

Input File Name _____ 

Output File Name __ 

Parameter String siie ___ 


Figure 10.2. Configuration File Record for batcher Process (Sebat) 
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Configuration File Parameter String Entries for BATCHER 

The parameter string field of the configuration file record for this 
process contains the logical system name (sue). 
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SECTION 11 


BURSTER 


Description: Story Duplicator 

Standard Disk File Name(s): SSYSTEM.Sll.BURSTER 
Standard Process Name(s): SEBRT, SCBRT 

Description 

The burster Process is designed to “burst” and/or duplicate a story, 
and create auxiliary headers for transmission. 

When a story is transmitted, burster examines the destinations for the 
story and, for each outward bound address, creates an auxiliary header 
that is sent to the pre-queue for that destination. 


PSTAT of Editorial BURSTER Process 


;pstat SEBRT 

Process SEBRT (1,75) was created by: SZEUS 
Program file name is SSYSTEM.SII.BURSTER 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 125 and current priority is 125 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 298 bytes 
File 1 is SO (R/W, Si 
File 2 is WP.SERCV (R/w. Si 
File 4 is SDATA.EDITOR.HEADER (R, Si 

File 7 is SSYSTEM.EDITOR.BURSTQ (R/W. Si. last error was 1 
File 8 is SSYSTEM.EDITOR.DUPQ (R/W, Si 
File 10 is SDATA.EDITOR.BASKET (R. Si 

File 11 is SSYSTEM.EDITOR.BUSTQ (R/w. Si. last error was 1 

File 12 is SEMSG (R/W. Si 

File 13 is SETR1 (R/W. Si 

File 14 is SOTMN (R/W, Si 

File 15 is SEUPD lR/W. Si 



Figure 11.1. pstat Information for Editorial burster Process (Sesrt) 
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Configuration File Record for 
Editorial BURSTER Process 


System E Record type 0_ Process type 23 Record #258 

Process Name SEBRT _ 

Program file name SSYSTEM.SII.BURSTER _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs 0_ 

Priority 125 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class BURST Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name _ 

Parameter String siie;burster;Ssystem. editor, burstq; 
Ssystem.editor.bustq 


Figure 11.2. Configuration File Record for Editorial burster Process (Sebrt) 


Configuration File Parameter String Entries for BURSTER 
Process 

The parameter string field of the configuration file record for this 
process contains the logical system name (sue). 

PSTAT of Advertising BURSTER Process 


;pstat SCBRT 

Process SCBRT (0,53) was created by: SZEUS 
Program file name is SSYSTEM.SIX.BURSTER 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 125 and current priority is 125 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 298 bytes 
File 1 is $0 (R/W, S) 

File 4 is SSYSTEM.CLASS.HEADER (R, S) 

File 7 is SSYSTEM.CLASS.BURSTQ (R/W, S), last error was 1 
File 8 is SSYSTEM.CLASS.DUPQ (R/W, S), last error was 1 
File 10 is SSYSTEM.CLASS.BASKET (R, S) 

File 11 is SCMSG (R/W, S) 

File 12 is SCTR (R/W, S) 

File 13 is SCUPD (R/W, S) 

Figure 11.3. pstat Information for Advertising burster Process (Scbrt) 
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Configuration File Record for 
Advertising BURSTER Process 


System C Record type 0_ Process type 23 Record #177 

Process Name SCBRT _ 

Program file name $SYSTEM.SII.BURSTER _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs 0_ 

Priority 125 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class BURST Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name _ 

Parameter String siic;burster;$system.class.burstq; _ 

Ssystem. class, bustq 


Figure 11.4. Configuration File Record for Advertising burster Process (cbrt) 


REQUEST Functions for CBRT and EBRT 


Listed below are the various requests that can be given to cbrt and 
EBRT. 

REQUEST ACTION 

11 Close files. 

12 Die gracefully. 
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SECTION 12 

CMON 

Description: Command Interpreter Monitor 
Standard Disk File Name(s): SSYSTEM.SYSTEM.CMON 
Standard Process Name(s): SCMON 

Description 

When a default run line is created for a process, cmon assigns run 
priorities and cpus by default, cmon is used only for defaults; any time an 
operator manager specifies a particular cpu or priority, Scmon is overrid¬ 
den. 

The List ( |cmd| (xj) “cmon” (no path or key required) lists the program 
name, its priority and the cpu (“x”)in which it will run by default. More than 
one x can be entered. The absence of an x allows guardian to make the 
cpu selection. 


Program 

Pr i 

0123456789012345 

FSTAT 

195 


PSTAT 

195 


READYQ 

195 


AOPR 

190 

X 

COMINT 

170 


ECONTROL 

140 


CCONTROL 

140 


INSPECT 

197 

X X X X 


Figure 12 . 1 . cmon Listing 


PSTAT of CMON Process 


;pstat SCMON 

Process SCMON (0.26 & 1,26) was created by; SZ000 
Program file name is SSYSTEM.SYSTEM.CMON 
Creation ID = 255.255 and process ID = 255.255 
Creator may stop process, and no one has tried. 

Initial priority was 176 and current priority is 176 


File 0 is SRECEIVE (R/W. Si 

Request 1 is READUPDATE for 178 bytes 
File 1 is SO (R/W. S) 

File 2 is SSYSTEM.SYSDATA.CMON (R/W. Si 

Figure 12.2. pstat Information for cmon Process (Scmon) 
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CMON Run Command 

The cmon run command may be entered in the following format from 
the Sll Command Interpreter or from an obey file (see obey.startup obey 
file, Section 99). 

cmon /name Scmon, in Ssystem.sysdata.cmon, out $0, pri 149, nowait/ 
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SECTION 13 

CRCHECK 

Description: Credit Check 

Standard Disk File Name(s): SSYSTEM.SII.CRCHECK 
Standard Process Name(s): SCRCK 

Description 

crcheck is a server process that performs credit checking functions for 
the requestor. The primary purpose of this process is to reduce the amount 
of time spent by cupdateh and ccontrol for credit checking (see the 
System/55 Advertising Management Manual [S55-029]). 

PSTAT of the Credit Check Process 


;pstat SCRCK 

Process SCRCK (1,60) was created by: SZEUS 
Program file name is SSYSTEM.SII.CRCHECK 
Creation ID = 254,255 and process ID = 254.255 
Creator may stop process, and no one has tried. 

Initial priority was 132 and current priority is 132 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 508 bytes 
File 1 is SO (R/W, S) 

File 2 is SSYSTEM.CLASS.CREDINIT (R/W, P) 

File 5 is SSYSTEM.CLASS.CREDIT (R. S) 

File 6 is SSYSTEM.CLASS.CREDIT (R, S) 

Figure 13.1. pstat Information for Credit Check Process (Scrck) 


Configuration File Record for Credit Check Process 


System C Record type 0_ Process type 31 Record #147 

Process Name SCRCK _ 

Program file name SSYSTEM.SII.CRCHECK _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs -1 

Priority 132 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class CREDIT Reference name _ 

Home Terminal_Rund _ 

Input File Name _ 

Output File Name _ 

Parameter String STIC. 01. 00: 00. CLASS. CREDINIT __ 


Figure 13.2. Configuration File Record for Credit Check Process (Scrck) 
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Configuration File Parameter String Entries for SCRCK 

The parameter string field of the configuration file record for this 

process contains the following: 

Logical system name, (sue) 

Initialization time. This must be entered in the form of HH:MM:SS (for 
example, 01:00:00). Scrck will scan the bad credit file and initialize 
the key pool at this specified time each day. Initialization should be 
done during the period of lowest system activity and should closely 
follow the scheduled completion of the bad credit file update. Scrck 
will not re-initialize if the bad credit file has not been modified during 
the 24 hours prior to initialization time. 

Initialization file. The file name of an unstructured disk file which will be 
used at each initialization time to store the current credit file bit map. 
In the event Scrck dies or is stopped for some reason, this file will be 
read to initialize the bit map pool, rather than re-reading the entire 
credit file. This file should be defined with at least 20 page extents. 

REQUEST Functions for CRCK 

Listed below are the various requests that can be given to crck. 

REQUEST ACTION 

iO Re-initialize. 

i4 Reply with statistics to requestor. 
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SECTION 14 

UPDATEH and CUPDATEH 


Description: Header Update Process 

Standard Disk File Name(s): SSYSTEM.Sll.UPDATEH 

SSYSTEM.S1I. CUPDATEH 
Standard Process Name(s): SEUPD, SCUPD 


Description 

updateh (editorial) and cupdateh (advertising) are NonStop server 
processes that are used by just, save, vcontrol, and purge to update 
the story and ad header file. These processes take in requests to add, 
delete, or change a story or ad header, acting on the request accordingly. 
The actual i/o to the header file is a NonStop process to minimize the 
chance of contaminating the alternate key files to the header file, thus 
ensuring that all cross-reference fields are updated in the event of a 
Tandem processor failure. 

PSTAT of CUPDATEH Process 


;pstat SCUPD 

Process SCUPD (0,47 & 1.65) was created by: SZEUS 
Program file name is SSYSTEM.SII.CUPDATEH 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 160 and current priority is 160 


File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 2054 bytes 


File 

File 

File 

File 

File 

File 

File 

File 

File 

File 

File 

File 

File 

File 

File 

File 

File 

File 

File 

File 

File 


I is $0 (R/W. S), last error was 26 

6 is SCTW (R/W. S) 

7 is SCMSG (R/W. S) 

8 is SCFIO (R/W. S) 

9 is SCBRT (R/W. S) 

10 is SCRCK iR./W. S) 

II is SSYSTEM. CLASS.DUMPITEM (R/W, S). last error 

12 is SCTR (R/W, Si 

13 is SSYSTEM.CLASS.HEADER iR/W. Si 

14 is SSYSTEM.CLASS.CLR (R/W, S) 

15 is SSYSTEM.CLASS.SALES (R/W. S) 

16 is SSYSTEM.CLASS.PAYMENTS (R/W, S) 

17 is SCFIL iR/W, S) 

18 is SCLIN (R/W, S) 

19 is SSYSTEM.CLASS.CREDIT (R. S), last error was 

20 is SSYSTEM.CLASS.CLASSC (R. S) 

21 is SSYSTEM.CLASS.ADTYPEC iR. S) 

22 is SDATA.CLASS.CONTROL iRW. Si 

23 is SDATA.SYSDATA.RESPONSE <R. S) 

24 is SSYSTEM.CLASS.CLDEPT «R. S) 

25 is SSYSTEM.CLASS.SEQUENCE (R. S) 


was 


1 


1 


Figure 14.1. pstat Information for Advertising Header Update Process (Scupd) (partial) 
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File 26 is SSYSTEM.CLASS.BASKETGP (R, S) 

File 27 is $SYSTEM.CLASS.BASKET (R, S) 

File 28 is SSYSTEM.CLASS.DESK (R, S) 

File 29 is SDATA.CLASS.QEXTRACT (R, S) 

File 30 is SDATA.CLASS.PUBGROUP (R, S) 

File 31 is SSYSTEM.CLASS.RATES (R. S), last error was 1 
File 32 is SDATA.CLASS.EXTRACTO (R/W, S) 

File 33 is SSYSTEM.CLASS.SPECRATE (R, S), last error was 1 
File 34 is SSYSTEM.CLASS.DEADLINE (R, S) 

File 35 is SCGOD (R/W, S) 

Figure 14.1 . pstat Information for Advertising Header Update Process (Scupd) (concluded) 


Configuration File Record for CUPDATEH Process 


System C Record type 0_ Process type 10 Record #105 

Process Name SCUPD _ 

Program file name SSYSTEM.SII.CUPDATEH _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs -1 

Priority 160 Alt Priority 0_ Threshold 0_ Server 0__ 

Server Class UPDATE Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name 

Parameter String CLASC;H; _ 


Figure 14.2. Configuration File Record for cupdateh Process (Scupd) 


Configuration File Parameter String Entries for CUPDATEH 

The parameter string field of the configuration file record for this 
process may contain the entries listed below. Options should be entered 
as shown in the following example. The parameter names may be abbrevi-. 
ated, as long as they remain unique. 

(system); (process type); [CLEARADJUST]; [N0H0LDC0ST]; [COMMENTS] 
[ATREROUTEO,1 or 2][CLREROUTE 0,1 or 2][PREPROCEP (story name)] 
[PREPHEADER] 

Note: Options specified in any one cupdateh or csve process must be 
specified in all. 

system name —The name of the logical system on which this process is 
to run (for example, clasc). 

process type —Indicates whether this is a header update process (H), or 
a save (csve) process (s). 

clearadjust—cupd will clear the balance due field upon killing an ad 
that has never run. If the ad is killed before all start dates and the 
clearadjust option is taken, then any Total Cost adjustments (sepa¬ 
rate from adjustments to the ad/shopper cost) will be cleared. 

noholdcost —Sets the “cost" to 0 when an ad is killed after its start date, 
but was never dumped due to its being on hold. Using this option will 
avoid billing errors having to be reconciled at billing time and sus¬ 
pense balances having to be adjusted accordingly—for ads of this 
nature only. 
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If the ad is on hold and it is killed on or after any start date and the 
noholdcost option is taken, then all of the special costs will be 
cleared. 


comments —Allows user-inserted comments in the header to have prece¬ 
dence over system-inserted comments (so they are not written over, 
or shoved off the end of the comments field). Also, system comments 
will be inserted only if there is room for the entire comment, so as not 
to leave broken comments or dangling words. 


Parameter String Options Controlling Basket Routing 

The Composite Control Table is constructed based on the Control Ta¬ 
bles specified in the following four records: 

1. Customer Information Record 

2. Classification Record 


3. Ad Type Record 


4. Department Record 

The Classification and Ad Type records may be changed during the 
ad-creating and ad-filing process. Each time this change is made, a new 
Composite Control Table may be constructed. 

Different Control Tables may have different basket routing procedures, 
and the previous hold information may be important to certain sites. The 
following options give you more control over basket routing. 

Options for Change in ADTYPE 


atreroute o—If Ad Type changes, do nothing 

atreroute i —If Ad Type changes, clear the current hold, and allow 
re-routing 


atreroute 2 —If Ad Type changes, clear all holds and allow re-routing 


Options for Change in CLASS"NAME 

clreroute 0—If Class changes, do nothing 

clreroute i —If Class changes, clear the current hold, and allow re-rout¬ 
ing 

clreroute 2—If Class changes, clear all holds, and allow re-routing 


Notes 


Options for Class and options for Ad Type are independent of each 
other, so it is possible for you to clear all hold flags for an ad'type change 
(atreroute 2) and to clear only the current hold flag for a class'name 
change (clreroute i). However, be careful when you have different 
dear-hold Class and Ad Type options and both the ad's Class and Ad 
Type are changed at the same time. 


An ad will not be rerouted to the hold that it was previously released 
from if either the atreroute i or clreroute i option is used. For exam¬ 
ple. if atreroute i is specified in your cupdateh Configuration Record 
and the ad has already been released from all three holds (Super, Censor 
and Credit), then no matter what change you make to the Ad Type, the ad 


will not be rerouted. 


Since cupdateh now processes its basket routing based on these 
options, changes may have to be made to the Configuration file records at 
certain sites so that cupdateh works according to the site's present speci¬ 


fications. 


14.3 





UPDATEH and CUPDATEH 


Sll Processes 


preprocep —Specifies the story name of an ep (the pre-processing ep) to 
use early in the header processing. This ep is executed before 
cupdateh tests the ad’s category and billed status (cupdateh skips 
the bulk of header processing for ads that are not Category c or ads 
that have been billed). 

If the preprocep parameter is not used, there is no change to current 
processing. If used, the only change will be the ability to interject an 
error condition and stop further processing on the ad. This option 
might be used to make site-specific validation on non-classified or 
billed ads, or to perform some checks before main processing takes 
place. 

The ep should select a (cupdateh) response number in order to 
cause a validation error. Otherwise, processing is unchanged. 

prepheader —Make the “old” header available to the pre-processing ep 
(if that ep is used). This will cause an extra disk read, so you must 
consider the extra overhead before deciding to use this option. (The 
“old” header is available for some eps, but only when the header is 
being filed, and validation checks cannot be made at that time.) The 
current header can be checked for system-sensitive field changes via 
the “change bits” and “check bits” fields set by ccontrol using its q 
extracts. Other field changes might require the old header for compar¬ 
isons. 

Notes 

The preprocep parameters (without prepheader) have access to the 
following structures: 

fo = current header (cheader) 
fi through F8 = unused 
F9 = scratch 

The preprocep parameters (with PREPHEADER) have access to the 
following structures: 

fo = current header (cheader) 
fi = old header (cheader) 

F2 through F8 = unused 
F9 = scratch 

The formats of the ep parameters are different in order to reduce the 
possibility of any misunderstanding: if the ep requires the old header, the 
prepheader option must be used. 

Note also that the pre-processing ep will be allowed to operate on 
non-classified ads (category <> c). The ep should check specifically 
whenever classified concerns are involved. 
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UPDATEH and CUPDATEH 


PSTAT of UPDATEH Process 


;pstat SEUPD 

Process SEUPD (0.72 & 1.84) was created bv: SZEUS 
Program file name is SSYSTEM.SII.UPDATEH 
Creation ID = 254,255 and process ID = 254.255 
Creator may stop process, and no one has tried. 

Initial priority was 160 and current priority is 160 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 1542 bytes 
File 1 is $0 (R/W, S) 

File 5 is SETW (R/W, S) 

File 6 is SEMSG (R/W, S) 

File 7 is SEBRT (R/W, S) 

File 8 is SEFIO (R/W. S) 

File 9 is SDATA.EDITOR.HEADER (R/W, S) 

File 10 is SDATA.EDITOR.XBASKET (R/W, S) 

Figure 14.3. pstat Information for updateh Process (Seupd) 


Configuration File Record for UPDATEH Process 


System E Record type 0_ Process type 10 Record #13 

Process Name SEUPD _ 

Program file name SSYSTEM.SII.UPDATEH _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs -1 

Priority 160 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class UPDATE Reference name _ 

Home Terminal __ Rund _ 

Input File Name ___ 

Output File Name ___ 

Parameter String clase _ 


Figure 14.4. Configuration File Record update Process (Seupd) 


Configuration File Parameter String Entries for UPDATEH 

The parameter string field of the configuration file record for this 
process may contain the entry listed below. Options should be entered as 
shown in the following example. The parameter names may be abbreviat¬ 
ed, as long as they remain unique. 

system name —The name of the logical system on which this process is 
to run (for example, clasc). 
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REQUEST Functions for CUPD 

Listed below are the requests that can be given to cupd. 

REQUEST ACTION 

0,20 Close files and reset timer. 

i,20 Initialize CUPDATEH. Note that when an Advertis¬ 
ing Control Record is changed, you must perform 

this request function for each cupdateh process 
specified in the configuration file records (see QRE- 
QUEST, Section 82). 

i22 Die gracefully. 


REQUEST Functions for EUPD 

Listed below are the requests that can be given to eupd. 

request action 

i22 Die gracefully. 
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DATA 


SECTION 15 

DATA 


Description; Converts Text for Job Stream 
Standard Disk File Name(s): SSYSTEM.SII.DATA 
Standard Process Name(s): SEDTA, SCDTA 


Description 

data is a system overseer server process which handles a single re¬ 
quest to spool a story off to a job stream, processing each request to 
completion. 

A print process has been written for data which interprets the spooled 
data as a job stream and which activates appropriate processes as desig¬ 
nated in the job stream (for example, styl, gloss, mapgen) and then 
provides results back to the spooler, if requested. 


Instead of writing an output module for each output device not requiring 
justified copy, data provides the capability of translating the text of a story 
to any character set, requiring only that a translation table be defined for 
the specific device, data will translate the story as instructed and then 
output the result directly to a device (for example, raycomp) or to the 
Tandem spooling system, which can forward the data to a device. This 
translation is a character-by-character translation for outputting to the 
specified device. The Proof Key Record specifies the spooler location and 
mapgen and textgen tables for this translation. See the Data Files section 
for more information. 


PSTAT of Editorial DATA Process 


;pstat SEDTA 

Process SEDTA (1.69) was created by: SEGOD 
Program file name is SSYSTEM.SII.DATA 
Creation ID = 254.255 and process ID = 254.255 
Creator may stop process, and no one has tried. 

Initial priority was 100 and current priority is 100 

File 0 is $RECEIVE <R W. Si 

Request 1 is RE .ADC PD ATE for S6 bytes 
File 1 is SO (R/W. Si 
File 2 is SS (R/W. Si 
File 4 is SDATA.EDITOR.HEADER iR. Si 
File 5 is SSYSTEM.EDITOR.PROOFKEY (R. Si 
File 6 is SSYSTEM.EDITOR.MAPOBJ (R. Si 
File 7 is S SYSTEM. SYS DAT A.CONV iR. S) 

| File 9 is SETR1 (R W. Si 
File 10 is SEUPD iR/W. S) 


Figure 15.1. pstat Information for Editorial data Process (Sedta) 
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Configuration File Record for Editorial DATA Process 


System E Record type 0_ Process type 3_ Record #19 

Process Name SEPTA _ 

Program file name $SYSTEM.SII.DATA _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs -1 

Priority 100 Alt Priority 110 Threshold 5_ Server 0_ 

Server Class DATA Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name _ 

Parameter String SHE, SS, OUTPUT _ 


Figure 15.2. Configuration File Record for Editorial data Process (Sedta) 



Configuration File Parameter String Entries for DATA 

The parameter string field of the configuration file record for this 
process contains the name of the logical system (she) and the name of the 
spooler collector to be used ($s). 

PSTAT of Advertising DATA Process 


;pstat SCDTA 

Process SCDTA (1,49) was created by: SCGOD 
Program file name is SSYSTEM.SII.DATA 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Waiting for LREQ 

Has received LDONE 

will time out in 16.63 seconds 

Initial priority was 100 and current priority is 100 
S = 016630 P = 074635 E = 002427 L = 016627 
LISTEN LCB’s reserved: 0, LINK LCB's reserved: 0 
LISTEN LCB'S in use: 0, LINK LCB’S in use: 0 
I/O was last done to file 1, last error was 40 
File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 86 bytes 
File 1 is SO (R/W, S) 

File 4 is SSYSTEM.CLASS.HEADER (R, S) 

File 5 is SSYSTEM.CLASS.PR00FKEY (R, S) 

File 6 is SSYSTEM. CLASS.MAPOBJ (R, S) 

File 7 is SSYSTEM.SYSDATA.CONV (R. S) 

File 9 is SCTR (R/W, S) 

File 10 is SCUPD (R/W, S) _ _ 

Figure 15.3. pstat Information for Advertising data Process (Scdta) 
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Configuration File Record for Advertising 
DATA Process 


DATA 


System C Record type 0_ Process type 3_ Record #21 

Process Name SCDTA _ 

Program file name SSYSTEM.SII.DATA _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs 0_ 

Priority 100 Alt Priority 110 Threshold 5_ Server 0_ 

Server Class DATA Reference name _ 

Home Terminal _ Rund __ 

Input File Name _ 

Output File Name __ 

Parameter String SHE. $S. OUTPUT _ 


Figure 15.4, Configuration File Record for Advertising data Process (Scdta) 
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DOWNLD 


SECTION 16 

DOWNLD 

Description: Download Process 

Standard Disk File Name(s): SSYSTEM.Sll.DOWNLD 

Standard Process Name(s): SDNF1 

Description 

downld is a program used to send specific disk files to a tcu, vcu, or 
Coyote terminal and supply various “services" to it, such as informing it of 
the date and time, writing error messages on the console, receiving pro¬ 
gram table dumps from it, and so on. 

PSTAT of DOWNLD Process 


;pstat SDNF1 

Process SDNF1 (1,35 & 0.351 was created by: CLAS.01,027 
Program file name is SDATA.SII.DOWNLD 
Creation ID = 255,255 and process ID = 255,255 
Creator may stop process, and no one has tried. 

Initial priority was 89 and current priority is 89 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 132 bytes 
File 1 is SO (R/W, Si 

File 2 is SSYSTEM.SYSDATA.VDTCTRL (R. S) 

File 3 is SSYSTEM.SYSDATA.CONFIG (R. Si 
File 4 is SSYSTEM.COYOTE.KELP (R. S) 

File 5 is SDATA.FONT.HELP iR, Si 

File 6 is SSYSTEM.COYOTE.PERSBOX (R. Si, last error was 1 
File 7 is SF1. #D00 (R/W, Ei 


File 

Request 1 is WRITEUPDATE 
8 is SF1. #D01 (R/W, Ei 

for 

0 

bytes 

File 

Request 1 is WRITEUPDATE 
9 is SF1. #D02 (R/W. El 

for 

0 

bytes 

File 

Request 1 is WRITEUPDATE 
10 is SF1. #D03 (R/W. Ei 

for 

0 

bytes 

File 

Request 1 is WRITEUPDATE 
11 is SF1 #D04 iR/W. El 

for 

0 

bytes 

File 

Request 1 is WRITEUPDATE 
12 is SF1. #D05 (R/W. Ei 

for 

0 

bytes 

File 

Request 1 is WRITEUPDATE 
13 is SF1. #D06 (R W. El 

for 

0 

bytes 

File 

Request 1 is WRITEUPDATE 
14 is SF1. #D07 (R/W. Ei 

f or 

0 

bytes 

File 

Request 1 is WRITEUPDATE 
15 is SFl. #D08 (R/W. Ei 

for 

0 

bytes 

File 

Request 1 is WRITEUPDATE 
16 is SFl. #D09 (R/W. Ei 

for 

0 

bytes 


Request 1 is WRITEUPDATE 

for 

0 

bytes 


Figure 16 . 1 . pstat Information for downld Process (Sdnfi) (partial) 


16.1 









DOWNLD 


Sll Processes 


File 17 is SF1. #D10 (R/W, E) 

Request 1 is WRITEUPDATE for 0 bytes 
File 18 is $F1.#D11 (R/W, E) 

Request 1 is WRITEUPDATE for 0 bytes 
File 19 is $F1. #D12 (R/W, E) 

Request 1 is WRITEUPDATE for 0 bytes 
File 20 is $F1.#D13 (R/W, E) 

Request 1 is WRITEUPDATE for 0 bytes 
File 21 is $F1.#D14 (R/W, E) 

Request 1 is WRITEUPDATE for 0 bytes 
File 22 is $F1.#D15 (R/W, E) 

Request 1 is WRITEUPDATE for 0 bytes 

Figure 16.1. pstat Information for downld Process (Sdnfi) (concluded) 


REQUEST Functions for DOWNLD (ET/ 960 s only) 

Listed below are the requests that can be given to downld for ET/960s 
only. 

REQUEST ACTION 

i0“$fx” Sends a message to vcu $fx “vcu will be down¬ 

loaded soon.” 


) 
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SECTION 17 

FILTER 


Description: Filter Process 

Standard Disk File Name(s): SSYSTEM.SII.F1LTER 
Standard Process Name(s): SEFIL, SCF1L 

Description 

filter is a program that gets requests to compile specified directory 
filtering methods and Extended Processes (eps). Directory filtering meth¬ 
ods are stories in which you specify criteria for selecting and/or rejecting 
directory items. The filter may be used to read certain fields in story or ad 
headers, eliminating all stories or ads not meeting specified criteria. (Direc¬ 
tory filtering is covered in detail in the Directory Filtering Manual [S55- 
016]). 

The filter compiler and its processor (select'record) have many 
uses besides filtering directories. It is more correct to call the filter process 
an external process. External processes have extensive use in classified. 

External Processes are explained more fully in the forthcoming 
System/55 External Processes Syntax Manual (S55-050). 

PSTAT of Advertising FILTER Process 


;pstat SCFIL 

Process SCFIL (0,52) was created by: SZEUS 
Program file name is SSYSTEM.SII.FILTER 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 135 and current priority is 135 

File 0 is SRECEIVE (R/W, Si 

Request l is READUPDATE for 172 bytes 
File 1 is SO (R/W, Si 
File 4 is SCTR (R/W, S> 

File 5 is SSYSTEM. CLASS.HEADER (R. S) 

File 6 is SSYSTEM.Q.QFIELD (R. Si 

Figure 17.1. pstat Information for Advertising filter Process (Scfil) 
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Configuration File Record for 
Advertising FILTER Process 


System C Record type 0_ Process type 22 Record #50 

Process Name SCFIL _ 

Program file name $SYSTEM.SII.FILTER _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs 0_ 

Priority 135 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class FIL Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name __ 

Parameter String siic __ 


Figure 17.2. Configuration File Record Advertising filter Process (Scfil) 


Configuration File Parameter String Entries for FILTER 

The parameter string field of the configuration file record for this 
process contains the logical system name (sue). 

PSTAT of Editorial FILTER Process 


;pstat $EFIL 

Process SEFIL (1,74) was created by: $ZEUS 
Program file name is SSYSTEM.SII.FILTER 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 135 and current priority is 135 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 172 bytes 
File 1 is $0 (R/W, S) 

File 4 is SETRl (R/W, S) 

File 5 is SDATA.EDITOR.HEADER (R, S) 

File 6 is SSYSTEM.Q.QFIELD (R , S) _ 

Figure 17.3. pstat Information for Editorial filter Process (Sefil) 
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FILTER 


Configuration File Record for Editorial FILTER Process 


System E Record type 0_ Process type 22 Record #77 

Process Name SEFIL _ 

Program file name SSYSTEM.SII.FILTER _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs 0_ 

Priority 135 Alt Priority p_ Threshold 0_ SOTver 0_ 

Server Class FIL Reference name _ 

Home Terminal ___ Rund _ 

Input File Name .... 

Output File Name ____ 

Parameter String siie ___ 


Figure 17 . 4 . Configuration File Record Editorial filter Process (Sefil) 
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SECTION 18 

FIO 


Description: File I/O Process 

Standard Disk File Name(s): SSYSTEM.SII.FIO 

Standard Process Name{s): SEFIO, SCFiO 

Description 

This program performs disk i/o to any data file on behalf of its request¬ 
ors. The process maintains records in a buffer pool to try to avoid the i/o. 
This significantly reduces the average response time to display a list or 
directory. 


PSTAT of Advertising FIO Process 


;pstat SCFIO 

Process SCFIO (0,48 & 1,55) was created by: SZEUS 
Program file name is SSYSTEM.SII.FIO 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 155 and current priority is 155 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 2130 bytes 
File 1 is SO (R/W, S) 

File 2 is SDATA.CLASS.USERS (R/W, S) 

File 3 is SSYSTEM.CLASS.CUSTINFO (R/W, S). last error was 1 
File 4 is SSYSTEM.CLASS.BASKET (R/W, S) 

File 5 is SSYSTEM.CLASS. DESK (R/W, S) 

File 6 is SSYSTEM.CLASS.MSGFILE (R/W, S). last error was 1 
File 7 is SSYSTEM.CLASS.LMSG (R/W, S) 

File 8 is SSYSTEM.CLASS.ADTYPEC (R/W, Si 
File 9 is SDATA.SYSDATA.DEVTABLE (R/W, SI 

File 10 is SSYSTEM.CLASS.METHOD (R/W. S). last error was 11 


Figure 18 . 1 . pstat Information for Advertising fio Process (Scfio) 
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System C Record type 0_ Process type 12 Record #34 

Process Name $CFIO _ 

Program file name SSYSTEM.SII.FIO _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs -1 

Priority 155 Alt Priority 0_ Threshold 0_ Server 0. 

Server Class FILIP Reference name _ 

Home Terminal _ Rund _ 

Input File Name __ 

Output File Name __ 

Parameter String ___ 


Figure 18.2. Configuration File Record for Advertising fio Process (Scfio) 


Configuration File Parameter String Entries for FIO 

The parameter string field of the configuration file record for this 
process may contain the maximum number of records (max'records) that 
can be stored (default 200). 

PSTAT of Editorial FIO Process 


;pstat $EFI0 

Process SEFIO (1,71 & 0,75) was created by: SZEUS 
Program file name is SSYSTEM.SII.FIO 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 155 and current priority is 155 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 2130 bytes 
File 1 is $0 (R/W, S) 

File 2 is SDATA.EDITOR.USERS (R/W, S) 

File 3 is SDATA.EDITOR.BASKET (R/W, S) 

File 4 is SSYSTEM.EDITOR.DESK (R/W, S) 

File 5 is SDATA.EDITOR.MSGFILE (R/W, S) 

File 6 is SDATA.EDITOR.LMSG (R/W, S) 

File 7 is SSYSTEM.SYSTEM.SYSTEMS (R/W, S) 

File 8 is SSYSTEM.EDITOR.DSTGRPS (R/W, S), last error was 1 
File 10 is SSYSTEM.EDITOR.PROOFKEY (R/W, S) _ 

Figure 18 . 3 . pstat Information for Editorial fio Process (Sefio) 
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Configuration File Record for Editorial FIO Process 


System E Record type 0_ Process type 12 Record #54 

Process Name SEFIQ _ 

Program file name SSYSTEM. SI I. FIO _. 

Primary CPU 0_ Alternate CPU 1_ Available CPUs ^ 1 ^ 

Priority 155 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class FILIP Reference name _ 

Home Terminal __ Rund _ 

Input File Name __ . _ 

Output File Name ___ 

Parameter String _ _ _ 



Figure 18 . 4 . Configuration Fiie Record Editorial fio Process (Sefio) 


REQUEST Functions for FIO 


Here is a list of the various requests that can be given to fio: 


i9 


REQUEST 


ACTION 

close all files 


% 
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SECTION 19 

GSTAT 

Description: Transaction Accumulator 
Standard Disk File Name(s): SSYSTEM.Sli.GSTAT 
Standard Process Name(s): $STAT 

Description 

gstat accumulates transactions from various processes, blocking and 
writing the transactions to a disk data file (structured or unstructured) or 
magnetic tape. When an unstructured or relative file gets full, the process 
starts writing over records starting at the beginning of the file. If any other 
type of file to which the process is writing gets full, the process prints an 
appropriate error message and stops. 

PSTAT of GSTAT Process 


;pstat Sstat 

Process SSTAT (0,41) was created by: CLAS.01.040 
Program file name is $SYSTEM.SII.GSTAT 
Creation ID = 255,255 and process ID = 255,255 
Creator may stop process, and no one has tried 

Initial priority was 148 and current priority is 148 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 256 bytes 
File 1 is SSYSTEM.EDITOR.VDTSTAT (R/W, S) 

Figure 19.1 . pstat Information for gstat Process (Sstat) 

GSTAT Run Command 

The gstat run command may be entered in the following format from 
the Sll Command Interpreter or from an obey file (see OBEY.STATS obey 
file, Section 99). 

run Sdata.sii.gstat / name Sostat, out Ssystem.editor.olstat, no¬ 
wait, pri 148, cpu 1/ 

name (process name)—The name given the process. 

out (out file name)—The name of the file where transactions will be 
logged. 

nowait —Specifies that the Command Interpreter prompt be returned 
without waiting for the Sstat process to complete. 

(logical system name)—The system for which operator messages will be 
gathered (for example, she). 
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SECTION 20 

HYPHEN 

Description: Hyphenation Process 

Standard Disk File Name(s): SSYSTEM.S1I.HYPHEN 

Standard Process Name(s): SEHYF, $CHYF 

Description 

hyphen is a just server process that attempts to hyphenate words that 
are passed to it. Requests contain the word to be hyphenated; the reply 
includes all hyphenation points found (if any), hyphen can keep track of 
approximately 8,000 commonly used words and avoid disk i/o and compu¬ 
tations on these words. 

PSTAT of Advertising HYPHEN Process 


;pstat SCHYF 

Process SCHYF (0,49) was created by: SZEUS 
Program file name is SSYSTEM.SII.HYPHEN 
Creation ID = 254,255 and process ID = 254.255 
Creator may stop process, and no one has tried. 

Initial priority was 115 and current priority is 115 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 42 bytes 
File 1 is SO (R/W. S) 

File 3 is SSYSTEM.DICT.HYPHTAB (R/W, S) 

File 4 is SDATA.DICT.MASTER (R, S) 

Figure 20.1. pstat Information for Advertising hyphen Process (Schyf) 


Configuration File Record for 
Advertising HYPHEN Process 


System C Record type 0_ Process type 13 Record #91 

Process Name SCHYF _ 

Program file name SSYSTEM.SII.HYPHEN _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs 0_ 

Priority 115 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class HYPHEN Reference name _ 

Home Terminal _ Rund _ 

Input File Name SSYSTEM.SYSDATA.CONFIG _ 

Output File Name _ 

Parameter String siic;Ssvstem.PICT.SUFFIX: _ 

Ssvstem.diet.hyphtab:Ssvstem.PICT.PROBT 


Figure 20.2. Configuration File Record for Advertising hyphen Process (Schyf) 
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Configuration File Parameter String Entries for HYPHEN 

The parameter string field of the configuration file record for this 
process contains the logical system name (sue); the suffix table ($sys- 
tem.dict.suffix); the hyphen hit list (Ssystem.dict.hyphtab) that hy¬ 
phen will read from at startup time) and, the probability table data file for 
performing probability analysis during hyphenation ($system.dict.probt). 

PSTAT of Editorial HYPHEN Process 


;pstat $EHYF 

Process SEHYF (0,74) was created by: $ZEUS • 

Program file name is $SYSTEM.SII.HYPHEN 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 115 and current priority is 115 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 42 bytes 
File 1 is $0 (R/W, S) 

File 3 is $SYSTEM.DICT.HYPHTAB (R/W, S) 

File 4 is $DATA.DICT.MASTER (R, S) 

Figure 20.3. pstat Information for Editorial hyphen Process (Sehyf) 


Configuration Fiie Record for 
Editorial HYPHEN Process 


System E Record type 0_ Process type 13 Record #17 

Process Name SEHYF _ 

Program file name SSYSTEM.SII.HYPHEN _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs 0_ 

Priority 115 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class HYPHEN Reference name _ 

Home Terminal _ Rund _ 

Input File Name $SYSTEM.SYSDATA.CONFIG _ 

Output File Name __ 

parameter String E:Ssvstem.DICT.SUFFIX:Ssvstem.diet.hyphtab; 
Ssvstem. DICT. PROBT 


Figure 20.4. Configuration File Record for Editorial hyphen Process (Sehyf) 

REQUEST Functions for EHYF and CHYF 

Listed below are the various requests that can be given to ehyf and 

CHYF. 

REQUEST ACTION 

i3 Write current hist list in CPU to hit list file on disk. 
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SECTION 21 

INMON 


Description: Input Monitor 

Standard Disk File Name(s): SSYSTEM.SII.INMON 
Standard Process Name(s): SINMN 

Description 

inmon, the Input Monitor, is a Tandem Perusal Process. It uses stan¬ 
dard Tandem Spooler procedures to communicate with the Spool Supervi¬ 
sor and the spooling file, inmon is run by the Sll system overseer ($zeus). 
If inmon stops for some reason, the overseer will resurrect it. 

For further information see the System/55 Input Spooling System Man¬ 
ual (S55-033). 


PSTAT of INMON Process 


;pstat Sinmn 

Process $INMN (1.162) was created by: SZEUS 
Program file name is SSYSTEM.SII.INMON 
Creation ID = 254,255 and process ID = 255.255 
Creator may stop process, and no one has tried 

Initial priority was 134 and current priority is 134... 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 244 bytes 
File 1 is SISPL (R/W, S) 

File 2 is SSYSTEM.EDITOR.ILINCHAR (R, Si, last error was 1 
File 3 is SSYSTEM.EDITOR.ILSTATUS (R/W, S) 

File 4 is SO (R/W. Si 

File 5 is SEMSG (R/W. S), last error was 11 

Figure 21.1. pstat Information for inmon Process (Sinmn) 


Configuration File Record for INMON Process 


System E Rec 0_ Process type 21 Record #355 

Process Name SINMN _ 

Program file name SSYSTEM.SII.INMON _ 

Primary CPU 1_ Alternate CPU 2 Available CPUs ^1 _ 

Priority 134 Alt Priority o _ Threshold 0 _ Server 0 _ 

Server Class INMON Reference name _ 

Home Terminal SOSP _ Rund 

Input file name _ 

Output file name __ 

Parameter string siie:Sispl; wire console: : 5: debug 


Figure 21.2. Configuration File Record for inmon Process (Sinmn) 
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Configuration File Parameter String Entries for INMON 

The parameter string field of the configuration file record for this 

process contains: 

she —The name of the system on which inmon is running. 

$ispl —The name of the spooling file collector where incoming copy is to 
be sent. If not specified, Sspls is used. 

wire console —The message group to send messages to if not specified 
for in the Input Line Characteristics Record. If this parameter is not 
specified and inmon doesn’t know the message group to send a 
message to, the console message will be logged normally but no 
message will be directed to a user group. 

(max idle time) —the number of seconds to wait before checking the 
components of the spooling system (default is 120). 

(MAX REPLY TIME)—the number of seconds to wait before replying to an 
intake (default is 5). 

(debug switch)—the switch for determining whether to call debug or just 
abend. If debug specified, will call debug before abending. 

REQUEST Functions for INMON 

Listed below are the various requests that can be given to inmon. 

REQUEST ACTION 

i2 Die gracefully. 
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~ SECTION 22 

JOBS 

Description: Spooler Print Process 
Standard Disk File Name(s): SSYSTEM.SII.JOBS 
Standard Process Name(s): 3JOBS, SRPRT 


Description 

jobs is the spooling system’s command interpreter and accepts com¬ 
mands from a spooling supervisor, and interprets each line, run com¬ 
mands cause jobs to newprocess the program according to the 
specifications, and submit spooled input to the process, until it is closed. 
jobs then resumes interpreting lines of spooled input, jobs may be run as 
follows: 

;jobs /out $0, pri 146, name SJOBS/ (logging file) 


jobs is normally run as a print process from the Spooling Configuration 
File, jobs is run as an associate print process, and must be named. All 
lines of input are written to (logging file), unless they are passed on to a 
process created by a run command. 

JOBS supports the following commands: 


RUN 

(IMPLIED RUN) 

PURGE (fileset list) 

CREATE (name) [, extent size 
RENAME (old name), (new name) 
VOLUME default subvol 
Sdefault vol 
Sdefault vol.default 


subvol 


COMMENT 

! (Also comment) 


PSTAT of JOBS Process 


;pstat SJOBS 

Process SJOBS (1.44) was created by: SSPLS 
Program file name is SSYSTEM.SII.JOBS 
Creation ID = 255.255 and process ID = 0.1 
Creator may stop process, and no one has tried. 

Initial priority was 146 and current priority is 146 

File 0 is $RECEIVE (R/W. Si 

Request 1 is READUPDATE for 132 bytes 
File 1 is SO (R/W, Si 
File 2 is SCMON (R/W. S) 

File 3 is SSPLS (R/W. Si 

Request 1 is WRITEREAD for 4 bytes 
File 5 is SS. #LOG.JOBS <R W. S) 


Figure 22.1. pstat Information for jobs Process (Sjoss) 
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SECTION 23 

JUST 

Description: Justification Process 

Standard Disk File Name(s): SSYSTEM.SII.JUST 

Standard Process Name(s): SEAJ1, SCAJ1 

Description 

just is a system overseer server process that handles a single justifica¬ 
tion request at a time, processing each request to completion. Requests 
are serialized and distributed by the system overseer to the various just 
processes which may be running on the system, just is capable of taking 
input directly from the text file (for justification requests done from a 
directory) and/or getting input directly from vcontrol when that process 
has changed text that needs to be justified. 

just uses the process textr to read from the text file; textw to write to 
the text file; hyphen to hyphenate words (there is no hyphenation logic in 
just), and updateh to update the story header file. 

The Advertising system differs from the Editorial system in that all copy 
is automatically justified by the system prior to filing it. In addition, if certain 
fields of information in the header are altered after the last justification, the 
system performs an automatic justification to check for possible error 
conditions. The requirement that all copy be saved in justified form on the 
Advertising system is implemented through ccontrol. 

More information about just is contained the Device and Font Manage¬ 
ment (S55-002). 
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PSTAT of Advertising JUST Process 


;pstat $CAJ1 

Process SCAJI (1,54) was created by: $CGOD 
Program file name is SSYSTEM.SII.JUST 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 105 and current priority is 105 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 86 bytes 
File 1 is $0 (R/W, S) 

File 2 is SSYSTEM.APS.FONTS (R, S) 

File 3 is SSYSTEM.APS.WIDTH (R. S) 

File 4 is SDATA.SYSDATA.RESPONSE (R, S) 

File 5 is SCUPD (R/W, S) 

File 6 is SCTR (R/W, S) 

File 7 is SCTW (R/W, S) 

File 8 is SCHYF (R/W, S) 

File 9 is SSYSTEM.CLASS.HEADER (R, S) 

File 10 is SSYSTEM.CLASS.STYLCODE (R, S) 

File 11 is SSYSTEM.CLASS.STYLINDX (R, S) 

File 12 is SSYSTEM.CLASS.STYLDESC (R, S) 

File 13 is SDATA.CLASS.USERS (R, S) 

File 14 is SSYSTEM. #0168 (R/W, S) 

File 15 is SSYSTEM.APS.KERN (R, S) 

Figure 23.1. pstat Information for Advertising just Process (Scaji) 


Configuration File Record for 
Advertising JUST Process 


System C Record type 3_ Process type 3_ Record #324 

Process Name SCAJI _ 

Program file name SSYSTEM.SII.JUST _ 

Primary CPU 2_ Alternate CPU 1_ Available CPUs 0_ 

Priority 103 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class APSJ Reference name JUST 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name _ 

Parameter String siic. aps, timeout, trap _ 

h 


Figure 23.2. Configuration File Record for Advertising just Process (Scaji ) 


Configuration File Parameter String Entries for 
JUST Process 

The parameter string field of the configuration file record for this 
process contains: 

sue—the logical system identifier for this justification process 
aps —the device to justify for 
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JUST 


(option) Any of the startup options, order is not important: 
trap— Arm processor traps 
TIMEOUT— Call SETLOOPTIMER 

void —Void cache between jobs 
debug —Debugging 

noadvance —Quadding commands don't begin line 

time out and trap are the normal options to include in the parameter 

string. 

PSTAT of Editorial JUST Process 


;pstat SEAJ1 

Process SEAJ1 (0,71) was created by: SEGOD 
Program file name is SSYSTEM.SII.JUST 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried 

Initial priority was 105 and current priority is 105 

File 0 is 8RECEIVE (R/W, S) 

Request 1 is READUPDATE for 86 bytes 
File 1 is SO (R/W, S) 

File 2 is SSYSTEM.APS.FONTS (R, S) 

File 3 is SSYSTEM,APS.WIDTH (R. S) 

File 4 is SDATA.SYSDATA.RESPONSE (R, S) 

File 5 is SEUPD (R/W, S) 

File 6 is SETR1 (R/W, S) 

File 7 is SETW (R/W, S) 

File 8 is SEHYF (R/W. S) 

File 9 is SDATA.EDITOR.HEADER (R. S) 

File 10 is SDATA.EDITOR.STYLCODE (R. S) 

File 11 is SDATA.EDITOR.STYLINDX (R. S) 

File 12 is SDATA.EDITOR.STYLDESC (R. S) 

File 13 is SDATA.EDITOR.USERS (R. S) 

File 14 is SSYSTEM. #0174 (R/W. Si 
File 15 is SSYSTEM.APS.KERN (R. Si 

Figure 23.3. pstat Information for Editorial just Process (Seaji) 


Configuration File Record for Editorial JUST Process 


System E Record type 0 _ Process type 3_ Record #109 

Process Name SEAJ1 _ 

Program file name SSYSTEM.Sll.JUST _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs -1 

Priority 105 Alt Priority 0_ Threshold 0 _ Server 1_ 

Server Class APSJ Reference name JUST 

Home Terminal __ Pund _ 

Input File Name __ 

Output File Name ____ 

Parameter String siie. aps. timeout, trap _ 


Figure 23 . 4 . Configuration File Record Editorial just Process (Seaji ) 
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SECTION 24 

LINAGE 

Description: Linage Total Update Process 
Standard Disk File Name(s): SSYSTEM.SII.LINAGE 
Standard Process Name(s): SCLIN 

Description 

linage is a NonStop process which dynamically updates in-memory 
linage totals following each addition, change, or deletion of an ad from the 
classified database. When a user calls up a linage record, the form proces¬ 
sor reads the record from the linage file and passes it to the linage 
accumulator process. This process then updates all totals in the record 
and passes it back for display on the vdt, giving the user the linage that is 
current as of the last finished ad. 

For detailed information on linage, see the Systeml55 Advertising 
Management Manual (S55-029). 

PSTAT of LINAGE Process 


: PSTAT SCLIN 

Process SCLIN (0,54 & 1,61) was created by: SZEUS 
Program file name is SSYSTEM.SII.LINAGE 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 161 and current priority is 161 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 2172 bytes 
File 1 is SO (R W, S) 

File 2 is SCLIN (W, S) 

File 5 is SSYSTEM.CLASS.CLINAGE (R/W, S) 

Figure 24.1. pstat Information for linage Process (Sclin) 


Configuration File Record for LINAGE Process 


System C Record type 0_ Process type 30 Record #78 

Process Name SCLIN _ 

Program file name SSYSTEM.SIT.LINAGE _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs z _l_ 

Priority 161 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class LINAGE Reference name _ 

Home Terminal __ Rund 

Input File Name _ 

Output File Name __ 

Parameter String siic _ 


Figure 24.2. Configuration File Record for linage Process (Sclin) 
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Configuration File Parameter String Entries for LINAGE 

The parameter string field of the configuration file record for this 
process contains the logical system name (sue). 

Device width. This is the maximum width of the device to use. If not 
specified, proof will use 132. 

Form name. This is the name of the form to use for putting out the header. 
Up to five form names may be specified. 

REQUEST Functions for CLIN 

Listed below are the various requests that can be given to clin. 

REQUEST ACTION 

10 Statistics request. The last initialization date/time 

and the number of current records are displayed. 

11 Re-initialize linage totals. 

12 Update all linage records. 




24.2 




Sll Processes 


MEMO 


SECTION 25 

MEMO 

Description: Automatic Memo Process 
Standard Disk File Name(s): SSYSTEM.Sil.MEMO 
Standard Process Name(s): SCMEM, SEMEM 

Description 

memo is the automatic messaging program which uses the message 
broadcaster to send messages at scheduled intervals, memo processes 
the records in the calendar message file and checks for additions to that 
file. If it is time to send a message, this program sends it to the message 
process for transmission. If there is a bad user or system name in the 
message to be sent, send time on the calendar entry is set to zero, and the 
contents of the record are returned to their creator. 

If there are backed up transmissions scheduled for a record when the 
process starts, the message is sent once and the send time is updated 
without transmission until send time is later than now. 

Use of the memo process is documented in the MEMO User's Manual 
(S55-054). 


PSTAT of Advertising MEMO Process 


;pstat SCMEM 

Process SCMEM (0,43) was created by: SZEUS 
Program file name is SSYSTEM.Sil.MEMO 
Creation ID = 254.255 and process ID = 255.255 
Creator may stop process, and no one has tried. 

Initial priority was 100 and current priority is 100 

File 0 is $RECEIVE (R/W. S) 

Request 1 is READ for 600 bytes 
File 1 is SO (R/W. S) 

File 2 is SDATA. CLASS. MEMODATA (R/W, S) . last error w'as 1 
File 3 is SSYSTEM.SYSTEM.SYSTEMS (R, S) 

File 6 is SCMSG (R/W. S) 

File 7 is SDATA.CLASS.USERGRP (R/W. S) 

-—___ I 


Figure 25.1. pstat Information 


for Advertising memo Process (Scmem) 
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Configuration File Record for 
Advertising MEMO Process 


System C Record type 0_ Process type 2_ Record #86 

Process Name $CMEM _ 

Program file name $SYSTEM.SII.MEMO _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs 0_ 

Priority 100 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class _Reference name _ 

Home Terminal _Rund __ 

Input File Name __ 

Output File Name _ 

Parameter String clasc;Sdata.class.memodata _ 


Figure 25.2. Configuration File Record for Advertising memo Process (Scmem) 



Configuration File Parameter String Entries for VPUT and 
VGET 

The parameter string field of the configuration file record for this 
process contains the logical system name (sue) and the name of the disk 
file that contains memo records. 

PSTAT of Editorial MEMO Process 


;pstat SEMEM 

Process SEMEM (1,68) was created by: SZEUS 
Program file name is SSYSTEM.SII.MEMO 
Creation ID = 254,255 and process ID = 255,255 
Creator may stop process, and no one has tried. 

Initial priority was 100 and current priority is 100 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READ for 600 bytes 
File 1 is SO (R/W. S) 

File 2 is SDATA. EDITOR.MEMODATA (R/W, S) 

File 3 is SSYSTEM.SYSTEM.SYSTEMS (R, S) 

File 6 is SEMSG (R/W, S) 

File 7 is SDATA.EDITOR.USERGRP (R/W, S), last error was 1 
Figure 25.3. pstat Information for Editorial memo Process (Semem) 
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Configuration File Record for Editorial MEMO Process 


System E Record type 0_ Process type 2_ Record #73 

Process Name SEMEM _ 

Program file name SSYSTEM.SII.MEMO _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs 0_ 

Priority 100 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class _ Reference name _ 

Home Terminal _ Rund __ 

Input File Name ___ 

Output File Name _ 

Parameter String clase;Sdata.editor.memodata _ 


Figure 25.4. Configuration File Record Editorial memo Process ($emem) 
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SECTION 26 

MESSAGE 


Description: Message Broadcaster 

Standard Disk File Name(s): SSYSTEM.Sll. MESSAGE 

Standard Process Name(s): $EMSG, SCMSG 


Description 

MESSAGE is a NonStop server process which broadcasts user mes¬ 
sages. It writes messages (as received by vcontrol or other processes 
which transmit messages) to a data file which is keyed on user name. In 
addition, if the target user is currently signed on to the system, message 
will relay the message to the appropriate vcontrol process. The 
vcontrol process is then responsible for notifying the target user on the 
vdt display that a message has been received. 

When sending a message to a group, the Message Broadcaster will 
write to each user’s message file in that group. It does this repetitively and 
then forwards to each vdt the message to be displayed, (see usergrp 
File in the Data Files section for more information about user groups.) 

Because message is a NonStop process, the list of signed-on users will 
not be lost in the event of a processor failure. 

PSTAT of Advertising MESSAGE Process 


:pstat SCMSG 

Process SCMSG (0.45 & 1.57) was created by: SZEUS 
Program file name is SSYSTEM.SII.MESSAGE 
Creation ID = 254.255 and process ID = 254.255 
Creator may stop process, and no one has tried. 

Initial priority was 145 and current priority is 145 

File 0 is SRECEIVE (R/W. S) 

Request 1 is READUPDATE for 326 bytes 
File 1 is SO (R/W. S) 

File 2 is SEMSG (R/W. Si * 

File 3 is SSYSTEM.SYSTEM.SYSTEMS iR. Si 

File 4 is SDATA.CLASS.USERGRP (R. Si. last error was 1 

File 5 is SDATA.CLASS.USERGRP (R. Si. last error was 1 

File 6 is SSYSTEM.CLASS.MSGFILE (R/W. Si 

File 7 is SDATA.CLASS.USERS (R. Si. last error was 1 

File 8 is SDATA.CLASS.USERS (R. S) 

Figure 26.1. pstat Information for Advertising message Process (Scmsg) 
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Configuration File Record for 
Advertising MESSAGE Process 


System C Record type 0_ Process type 7_ Record #30 

Process Name SCMSG _ 

Program file name $SYSTEM.SII. MESSAGE _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs -1_ 

Priority 145 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class MSG Reference name _ 

Home Terminal _ Rund _ 

Input File Name ____ 

Output File Name ____- 

Parameter String clasc _____ 


Figure 26.2. Configuration File Record for Advertising message Process (Scmsg) 


Configuration File Parameter String Entries for MESSAGE 

The parameter string field of the configuration file record for this 
process contains the logical system identifier (clasc) composed of the 
node name and the system id. 

PSTAT of Editorial MESSAGE Process 


•j 


File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 326 bytes 
File 1 is SO (R/W. S) 

File 2 is WP.SEMSG (R/W, S) 

File 3 is $SYSTEM.SYSTEM.SYSTEMS (R, S) , last error was 1 
File 4 is SDATA.EDITOR.USERGRP (R, S) , last error was 1 
File 5 is SDATA.EDITOR.USERGRP (R, S), last error was 1 
File 6 is SDATA.EDITOR.MSGFILE (R/W, S) 

File 7 is SDATA.EDITOR.USERS (R, S) 

File 8 is SDATA. EDITOR.USERS (R, SI, last error was 1 
File 9 is SCMSG (R/W, S) 

File 10 is CT.SCMSG (R/W, S) 

File 11 is LINK.SEMSG (R/W, S) 

File 12 is WP.SPMSG (R/W, S) 

File 13 is SII.SPMS G (R/W. S) _ 

Figure 26.3. pstat Information for Editorial message Process (Semsg) 


;pstat SEMSG 

Process SEMSG (1,70 & 0,73) was created by: SZEUS 
Program file name is SSYSTEM.SII.MESSAGE 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 145 and current priority is 145 
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Configuration File Record for 
Editorial MESSAGE Process 


System E Record type 0_ Process type 7_ Record #99 

Process Name SEFIO _ 

Program file name SSYSTEM.SII.MESSAGE _ 

Primary CPU 1_ Alternate CPU 0 _ Available CPUs 0_ 

Priority 145 Alt Priority 0 _ Threshold 0 _ Server 0_ 

Server Class MSG Reference name _ 

Home Terminal __ Rund _ 

Input File Name _ . _ _ 

Output File Name _ 

Parameter String clase ___ 


Figure 26.4. Configuration File Record Editorial message Process (Semsg) 


REQUEST Functions for CMSG and EMSG 

Listed below are the requests that can be given to cmsg and emsg. 

REQUEST ACTION 

il Close files and reopen (re-initialize). Used when 

adding new user or group. 
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SECTION 27 

OUTMON 


Description: Output Monitor 

Standard Disk File Name(s): SSYSTEM.SII.OUTMON 
Standard Process Name(s): SEMON 


Description 

outmon oversees the orderly transmission of text to external destina¬ 
tions. It controls access to the pre-queues by the outtake process, and 
implements all necessary line control functions requested from the vdt. 
See the WISPER Manual (S55-031) for more information. 

PSTAT of Editorial OUTMON Process 



;pstat Semon 

Process SEMON (1,115) was created by: SZEUS 
Program file name is SSYSTEM.SII.OUTMON 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 146 and current priority is 146 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 244 bytes 
File 1 is SO (R/W, S) 

File 2 is SSYSTEM.SYSDATA.CONFIG (R. S) 

File 3 is SDATA3.EDITOR.HEADER (R. Si 
File 4 is SEUP3 (R/W, S) 

File 5 is SEBRT (R/W. S) 

File 6 is SEMSG (R/W. S) 

File 7 is SSYSTEM.EDITOR.OLSTATUS (R/W, Si 

File 8 is SSYSTEM.EDITOR.OLINCHAR (R. S). last error was 1 
File 9 is SSYSTEM.EDITOR.DSTGRPS IR. Si 
File 10 is SSYSTEM.EDITOR.BASKET (R. Si 

File 11 is SDATA1.EDITOR.HEADER1 (R. Si, last error was 1 
bile 12 is SDATA3.EDITOR.HEADERO (R. Si 
pile 13 is SE001 (R/W. Si 

Figure 27.1. pstat Information for Editorial outmon Process (Semon) 
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Configuration File Record for 
Editorial OUTMON Process 


System E Rec 0_ Process type 24 Record #486 

Process Name SEMON _ 

Program file name $SYSTEM.SII.OUTMON _ 

Primary CPU 0__ Alternate CPU 1 Available CPUs -1 

Priority 125 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class OUTMON Reference name _ 

Home Terminal _ Rund 

Input file name _ 

Output file name _ 

Parameter string siie,kill,outmon _ 


Figure 27.2. Configuration File Record Editorial outmon Process (Semon) 



Configuration File Parameter String Entries for OUTMON 

The parameter string field of the configuration file record for this 
process contains: 

she— the name of the system on which outmon is runing 

kill— the name of a basket where outmon puts killed stories 

outmon —the name of the message group that is to receive alert mes¬ 
sages from outmon. 

REQUEST Functions for OUTMON ^ 

Listed below are the various requests that can be given to outmon. 

REQUEST ACTION 

i2,24’0,“!” Stops all outtakes nicely. 

i2 Sops SOTMN nicely. 



y 
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SECTION 28 

OUTTAKE 

Description: Output Line Control Process 
Standard Disk File Name(s): SSYSTEM.SII.OUTTAKE 
Standard Process Name(s): SEOOI 

Description 

The outtake process controls logical output lines as directed by out- 
mon, the output supervisor. There may be several outtake processes 
running on a particular logical system. See the WISPER Manual (S55-031) 
or more information. 

PSTAT of Editorial OUTTAKE Process 


;pstat SeoOl 

Process SEOOI (1,42) was created by: SZEUS 
Program file name is SSYSTEM.SII.OUTTAKE 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 103 and current priority is 103 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 244 bytes 
File 1 is $0 (R/W. S) 

File 2 is SDIAL (R/W, E) 

File 5 is SEUP2 (R/W.S) 

File 6 is SETR2 (R/W, S) 

File 7 is SETW (R/W, S) 

File 8 is SEMON (R/W. S) 

Request 1 is WRITEREAD for 56 bytes 
File 9 is SEBRT (R/W. S) 

File 10 is SDA.TA3. EDITOR. HEADER (R/W. S) , last error was 1 
File 11 is SSYSTEM.EDITOR.OLINCHAR (R, S) 

File 12 is SSYSTEM.EDITOR.HaNOBJR.iRSi S) 


Figure 28.1. pstat Information for Editorial outtake Process (Seooi ) 
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Configuration File Record for 
Editorial OUTTAKE Process 


System E Rec 0_ Process type 2_ Record #500 

Process Name SE001 _ 

Program file name $SYSTEM.SII.OUTTAKE _ 

Primary CPU 2_ Alternate CPU 0 Available CPUs -1 

Priority 85 Alt Priority 0_ Threshold 0_ Server 0. 

Server Class OTAKE Reference name _ 

Home Terminal _ Rund _ 

Input file name _ 

Output file name _ 

Parameter string siie _ 


Figure 28.2. Configuration File Record Editorial outtake Process (Seooi) 


Configuration File Parameter String Entries for OUTTAKE 

The parameter string field of the configuration file record for this 
process contains the name of the system on which outtake is running. 
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SECTION 29 

PROOF 

Description: Proof Process 

Standard Disk File Name(s): SSYSTEM.Sli.PROOF 

Standard Process Name(s): SEPRF, SCPRF 


Description 

proof is a process that handles proof requests from system users, 
directing these requests to a selected proofing device, such as a line 
printer, word processing printer, or other printing device. When mapgen 
formats and textgen tables are defined, and their names are entered in 
the Proof Key Record (see “The Proof Key Record"), proofing to non-ASCii 
printers is possible, (mapgen is documented in the MAPGEN User’s Man¬ 
ual [S55-032]; textgen in the Input Spooling System Manual , S55-033). 

Requests to proof are serialized, handled one at a time, and sent.by 
the system overseer to the various proof processes running on the sys¬ 
tem. 


Figure 29.1 shows a sample proof. Your proof header may contain fewer 
or different fields than this example. 


|PROOF of Story ‘#5366' Requested by MIKE iSA002i on 3,29 82 15:36:25 

Copied from story 4 #5168 * Entered 3/29/82 at 15:14 Expires 3/31,82 at 8:00 iOVERRIDEi Originator: AP-WIRE Author: MIKE 
Header text changed by MIKE (Text changed by MIKE at line 39) on 3/29 82 at 15:36:07 

Basket: MIKE WORK Level 0 from basket NATIONAL by MIKE on 3/29 82 at 15:32:53 
Desk: WIRE Level 1 

Topic: PHILADELPHIA Keyword: TRAINS COLLI Pub. DateL 3 30 82 Part: A Page. 1 Edition: MET1 
43 actual lines. 1.583 characters 

Default STYL: NEWS Device: APS i i Just Status. E 

Spell Status: * (Last spelled on 3 29 32 at 15:20:26 with 13 errors) 


Guide: AM-TrainsCollide 03-29 0250 
LN# TEXT 


1 <A2'AM-Trains Collide.250<ql> 

2 26 Injured In Train Collision Near Philly<ep- 

3 -AD BRISTOL. PA iAP> -- A stalled Boston- 

4 to-Philadelphia passenger train was 

5 rammed by a locomotive that had been 

6 sent to help tow it Monday, and 26 people 

7 were injured, none seriously, authorities 
3 said, ep■ 

9 Three of the injured were admitted to Bucks 

10 County hospitals and were in satisfactory or 

11 stable condition, while others were treated 

12 for cuts and bruises and released, ep 

13 Amtrak spokeswoman Debbie Marc iniak 

14 said the engineer of the six-car train report- 

15 

16 


Figure 29.1. A Sampie Proof Header and Proof 
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PSTAT for Editorial PROOF Process 


Process SEPRF (3,156) was created by: SEGOD 
Program file name is SSYSTEM.SII.PROOF 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 90 and current priority is 90 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 86 bytes 
File 1 is SO (R/W, S) 

File 2 is SDATA3. EDITOR.HEADER (R, S) 

File 4 is SETR3 (R/W, S) 

File 5 is SEVPT (R/W, S) 

File 6 is SSYSTEM.EDITOR.PR00FKEY (R, S) 

File 7 is SSYSTEM.EDITOR.MAPOBJ (R, S) 

File 8 is SSYSTEM.EDITOR. CONV (R, S) 

Figure 29.2. pstat Information for Editorial proof Process (Seprf) 


Configuration File Record for Editorial PROOF Process 

System E Record type 0_ Process type 3_ Record #21 

Process Name SEPRF _ 

Program file name SSYSTEM.SII.PROOF _ 

Primary CPU 0_ Alternate CPU 0_ Available CPUs 0_ 

Priority 90 Alt Priority 95 Threshold 10 Server 1_ 

Server Class PROOF Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name _ 

Parameter String clase, , *. 132, proof hdr _ 

dev width. 


Figure 29.3. Configuration Fiie Record for Editorial proof Process (Seprf) 

Configuration Fiie Parameter String Entries for PROOF 

The parameter string field of the configuration file record for this 

process contains the following: 

Logical system name, (sue) 

Spooler name. This will default to $S. if nothing else is entered. 

Justified spec. This is the value of the justified status, which means “Story 
has been justified, but isn’t currently.' proof will print output column if 
jusfstatus is equal to this. Enter “E” if you always want to see two 
columns, otherwise use The default is 

Device width. This is the maximum width of the device to use. If not 
specified, proof will use 132. 

Form name. This is the name of the form to use for putting out the header. 
Up to five form names may be specified. 
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PSTAT for Advertising PROOF Process 


Process SCPRF (1,49) was created bv: SCGOD 
Program file name is SSYSTEM.SII.PROOF 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 90 and current priority is 90 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 86 bytes 
File 1 is SO (R/W. S) 

File 2 is SSYSTEM.CLASS.HEADER (R. S) 

File 4 is SCTR (R/'W. S) 

File 5 is SCVGT (R/W, S) 

File 6 is SSYSTEM.CLASS.PROOFKEY (R, S) 

File 7 is SSYSTEM.CLASS.MAPOBJ (R, S) 

File 8 is SSYSTEM.SYSDATA.CONV (R, S) 


Figure 29.4. pstat Information for Advertising proof Process (Scprf) 


Configuration File Record for Advertising 
PROOF Process 


To access the configuration file record for the advertising proof pro¬ 
cess, type IcmdI [x] and complete the prompt as follows: 


List Name config 
Key Scprf* _ 


Path pn Hardcopy _ 


Type IcmdI [f] to display the first item listed. 


System C Record type 0_ Process type 3_ Record #25 

Process Name SCPRF _ 

Program file name SSYSTEM.SII.PROOF _ 

Primary CPU 0_ Alternate CPU 0_ Available CPUs 0_ 

Priority 90 Alt Priority 95 Threshold 10 Server 1_ 

Server Class PROOF Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name ___ 

Parameter String clasc. . *. 132. proof hdr _ 

dev width 


Figure 29.5. Configuration File Record for Advertising proof Process (Scprf) 


The PROOF Parameter String 

The entries in the parameter string field of the proof configuration 
file record control the appearance of the printed proof. These parameters 
are listed and explained below. 


(system) is the system identifier, such as e for Editorial or c for Advertising. 
It is required. 

(spooler name) defaults to $s if not specified. 

(justified spec) is the justification status indicator proof uses to determine 
whether to print input text only or output input text, proof checks the 
indicator in the justification'status field of the story header against 


the indicator entered here. 
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1. If a story is not justified, and the justification status matches the 
indicator in the parameter string, proof prints only input text. 

2. If the indicator in the parameter string is an asterisk (*), proof 
prints output text only if the take is currently justified. 

3. The letter e in the string causes proof to print output text and 
input text regardless of the justification status. 

Proofs from printers that use a mapgen format and textgen table display 
text as specified in the format and table. 

(dev width) specifies the maximum column width of the proofing device. 
proof uses the configured device width for the width of the proof. 
However, the printed width of all processes, in particular $s, is consid¬ 
ered to be 132 columns. So, if the width is not specified, proof will 
use 132 columns. Thus, stories proofed to Ss.versi will always be 
whichever width is less, 132 columns or the configured width. 

Examples of Startup Parameters 

In the examples below, the required commas in the parameter string are 
separated by spaces for easier reading. When entering parameters in the 
system, you need not separate the commas with spaces. 

To always print input and output text, up to a width of 100 columns: 

Parameter string e. , e, 100 _ 

To print only input and output text if justified, up to a width of 132 
columns: 

Parameter string e, , *, _ 

User Options for Proof Format 

Each user's User Defaults form contains eight user-changeable fields 
that govern certain aspects of proofing for that user. The options apply only 
to printers that do not use a mapgen format or textgen table. They are 
ignored if the proof field of the User Defaults contains the name of a Proof 
Key Record for a printer using mapgen and textgen. 

Figure 29.6 illustrates these fields. 




Proof _ 

Input text only? _ Output text only? _ Output commands? 
Suppress banner? _ Suppress line numbers? _ 

Double spacing? _ Triple 9 _ Proof copies _ 


Figure 29.6. The Proof Fields in the User Defaults Form 


proof —The entry in this field must match the entry in the key field of a 
Proof Key Record that defines the proof location for the user. 

input text only? —Enter x to have only input text printed. Default is both 
input and output text. 

output text only? —Enter x to have only output text printed. 

output commands? —Enter x to have output commands printed with 
output text. 
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suppress banner?— Enter x to specify the omission of the line beginning 
“Proof of story . . The first line of the form will be the first line of the 
proof. 

suppress line numbers? —Enter x to instruct proof not to print line 
numbers, column labels, and the line of dashes separating the header 
from the text. 

double spacing? —Enter x to specify double spacing of the printed proof. 
The default is single spacing. 

triple? —Enter x to specify triple spacing of the printed proof. 
proof copies —The number of copies to be printed of each proof. 

Representation of VDT Attributes on Proofs 

The input text column of a proof (displayed only on proofs from printers 
that do not use a mapgen format or textgen table) contains 16 symbols 
<ai) through <A16) to represent attributes 1 through 16 on the Coyote vdt. 
Whenever the attribute in the input text changes, the symbol for the new 
attribute is inserted in the input side of the proof. 

The symbols for the Coyote vdt and their meanings are shown in Table 
29.1, below. The attribute symbols are consistent with the keyboard layout 
and the styl typesetting language. Note that these are the normal dis¬ 
plays; you may change the displays for any and all attributes. 


Table 29.1 

Coyote VDT Display of STYL Attributes 

STYL Attribute 

Normal 

Number 

Display 

(A1> 

Normal 

<A2> 

Bold 

(A3) 

Strike-through 

(A4) 

Italic 

(A5) 

Dotted underscore 

(A6) 

Bold italic 

(A7) 

Bold dotted underscore 

(A8> 

Bold strike-through 

<A9> 

Italic strike-through 

(AO) 

Italic dotted underscore 

(All) 

Bold italic dotted underscore 

(A12) 

Bold italic strike-through 

<A13) 

Wavy underscore 

(A14) 

Bold wavy underscore 

(A15) 

Italic wavy underscore 

<A16> 

Bold italic wavy underscore 
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On the et/960 vdt the 10 symbols represent attributes 1 through 10. 
The symbols for the et/960 vdt and their meanings are shown in Table 
29.2. 


Table 29.2 

ET/960 VDT Display of STYL Attributes 

STYL Attribute 
Number 

How Displayed 

<A1> 

Normal 

<A2> 

Bright 

<A3> 

Strike-through 

(A4) 

Solid-underscore 

<A5> 

Broken-underscore 

<A6> 

Bright/Solid-underscore 

<A7> 

Bright/Broken-underscore 

(A8) 

Bright/Strike-through 

<A9> 

Strike-through/Solid Underscore 

(AO) 

Strike-through/Broken-underscore 


The proof process assumes a default of normal lightface for the first 
character of text. This means that an attribute symbol will appear before 
any text only if the attribute of the first character is not normal lightface. 


You may define attribute meanings in styl procedures to suit your own 
applications. 
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SECTION 30 

PURGE 

Description: Automatic Purge Process 
Standard Disk File Name(s): SSYSTEM.SII.PURGE 
Standard Process Name(s): SCPRG, SEPRG 

Description 

purge is a stand-alone utility process run and monitored by zeus. 
purge scans the list of stories that are going to expire (using path ex to the 
header file) and deletes those stories whose expiration dates have 
passed. It deletes the current text, all previous audit copies and the header 
file record for each story. After all stories that are to be deleted are purged, 
purge delays for a configurable period of time before scanning the expire 
date list again. The period of time to delay is established in the configura¬ 
tion file entry for the purge process. The process runs continuously but at 
a very low process priority. 

PSTAT of Advertising PURGE Process 


;pstat SCPRG 

Process SCPRG (1,47) was created by: SZEUS 
Program file name is SSYSTEM.SII.PURGE 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 10 and current priority is 10 

File 0 is SRECEIVE (R/W, S), last error was 40 
Request 1 is READUPDATE for 2048 bytes 
File 1 is SO (R/W, S) 

File 3 is $S. #LOG.CPURGE (R/W. Si 

File 4 is SSYSTEM.CLASS.HEADER (R, Si 

File 5 is SDATA.CLASS.HEADER3 (R/W. Si 

File 7 is SCTW IR/W. Si 

File 8 is SCTR (R/W, Si 

File 9 is SCUPD (R/W, Si 

File 10 is SCGOD (R/W. Si 

File 11 is SSYSTEM.CLASS.DUMPITEM (R/W. Si. last error was 1 
File 12 is SCFI0 (R W. Si. last error was 1 
File 13 is SSYSTEM.DICT.SPELLH (R/W. Si 
File 14 is SSYSTEM.DICT.SPELLW (R/W. Si 

File 15 is SSYSTEM.CLASS.DUPQ (R/W. Si. last error was l 
File 16 is SSYSTEM.CLASS.STRINGS (R/W. Si. last error was 1 
File 17 is SSYSTEM.CLASS.TRACKING (R/W. Si 
File 18 is SSYSTEM. CLASS. JACKET (R/'W. Si 
File 19 is SDATA.CLASS.EXTRACT0 (R/W. Si 

Figure 30.1. pstat Information for Advertising purge Process (Scprg) 
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Configuration File Record for 
Advertising PURGE Process 


System C Record type 0_ Process type 2_ Record #33 

Process Name $CPRG _ 

Program file name $SYSTEM.SII. PURGE _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs 0_ 

Priority 10 Alt Priority 0_ Threshold 0_ Server 0 _ 

Server Class PURGE Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name _ 

Parameter String clasc; 10; Ss. #log.cpurge _ 


Figure 30.2. Configuration File Record for Advertising purge Process (Scprg) 


Configuration File Parameter String Entries for PURGE 

The parameter string field of the configuration file record for this 
process contains: 

clasc— the name of the logical system from which purge is deleting ads 
or stories. 

i o— the time in minutes between successive runs of purge. 

$s.#log.cpurge —the name of a file to report the date, time, and story 
number of each story purged. This is normally a spooling file location. 

PSTAT of Editorial PURGE Process 


;pstat $eprg 

Process $EPRG (1,67) was created by: SZEUS 
Program file name is $SYSTEM.SII.PURGE 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 10 and current priority is 10 

File 0 is $RECEIVE (R/W, S) , last error was 40 
Request 1 is READUPDATE for 2048 bytes 
File 1 is $0 (R/W, S) 

File 3 is $S. #LOG.EPURGE (R/W, S) 

File 4 is SDATA.EDITOR.HEADER (R, S) 

File 5 is $DATA.EDITOR.HEADER3 (R/W, S) 

File 6 is $DATA.EDITOR.HEADER2 (R, S), last error was 1 
File 8 is SETW (R/W, S) 

File 9 is $ETR1 (R/W, S) 


File 

10 

is 

$EUPD (R/W, S) 






File 

11 

is 

SEGOD (R/W, S) 






File 

12 

is 

SSYSTEM.DICT.SPELLH 

(R/W, S), 

last 

error 

was 

1 

File 

13 

is 

SSYSTEM.DICT.SPELLW 

(R/W, S), 

last 

error 

was 

1 

File 

14 

is 

SSYSTEM.EDITOR.DUPQ 

(R/W, S), 

last 

error 

was 

1 

File 

15 

is 

SDATA.EDITOR.STRINGS 

(R/W, S) . 

, last 

error 

’ was 


File 

16 

is 

SDATA.EDITOR.XBASKET 

(R/W, S) 






Figure 30.3. pstat Information for Editorial purge Process (Seprg) 
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Configuration File Record for Editorial PURGE Process 


System E Record type 0_ Process type 2_ Record #47 

Process Name SEPRG _ 

Program file name $SYSTEM.SII.PURGE _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs 0_ 

Priority 10 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class PURGE Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name _ 

Parameter String clase; 10; Ss. #log.epurge _ 


Figure 30.4. Configuration File Record for Editorial purge Process (Seprg) 

REQUEST Functions for EPRG and CPRG 

Listed below are the reauests that can be given to eprg and cprg. 

REQUEST ACTION 

i2 Die gracefully. 
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SECTION 31 

QUME 

Description: QUME Driver Process 

Standard Disk File Name(s): SSYSTEM.Sll.QUME 

Standard Process Name(s): SCQUM, SEQUM 

Description 

qume is a system overseer server process which outputs data to drive 
qume word processing printers, qume uses textr to read from the text file 
and spools its output to the designated spooling location using standard 
Tandem spooling procedures. See Device and Font Management (S55- 
002) for more configuration information. 

PSTAT of Advertising QUME Process 


;pstat SCQUM 

Process SCQUM (0.55) was created by: SCGOD 
Program file name is SSYSTEM.SII.QUME 
Creation ID = 254,255 and process ID = 254.255 
Creator may stop process, and no one has tried. 

Initial priority was 90 and current priority is 90 

File 0 is SRECEIVE (R/W. S) 

Request 1 is READUPDATE for 86 bytes 
File l is SO (R/W, Si 

File 2 is SSYSTEM.EDITOR.QUMEINFO (R, Si 

File 3 is SS (R/W. SI 

File 4 is SSYSTEM.QUME.WIDTH (R. S) 

File 6 is SCTR (R/W. Si 
File 7 is SCUPD (R/W. S) 

File 8 is SDATA.SYSDATA.SUBDEV (R. S) 

File 9 is SSYSTEM.CLASS.HEADER (R. Si _ 

Figure 31.1. pstat Information for Advertising qume Process (Scqum) 
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Configuration File Record for 
Advertising QUME Process 


System C Record type 0_ Process type 3_ Record #29 

Process Name SCQUM _ 

Program file name $SYSTEM.SII.QUME _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs 0_ 

Priority 90 Alt Priority 95 Threshold 10 Server 0_ 

Server Class QUME Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name _ 

Parameter String clasc, qume, Ssvstem.editor.qumeinfo,$s 


Figure 31.2. Configuration File Record for Advertising qume Process (Scqum) 



PSTAT of Editorial QUME Process 


;pstat SEQUM 

Process SEQUM (1,53) was created by: SEGOD 
Program file name is SSYSTEM.SII.QUME 
Creation ID = 254,255 and process ID = 254,254 
Creator may stop process, and no one has tried. 

Initial priority was 90 and current priority is 90 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 86 bytes 
File 1 is $0 (R/W, S) 

File 2 is SSYSTEM.EDITOR.QUMEINFO (R, S) 

File 3 is SS (R/W, S) 

File 4 is SSYSTEM.QUME.WIDTH (R, S) 

File 6 is SETR1 (R/W, S) 

File 7 is SEUPD (R/W, S) 

File 8 is SDATA.SYSDATA.SUBDEV (R, S) 

File 9 is SDATA.EDITOR.HEADER (R, S) 

Figure 31.3. pstat Information for Editorial qume Process (Sequm) 



Configuration File Record for 

Editorial QUME Process 


System E record type 0_ Process type 3_ Record #31 

Process Name SEQUM _ 

Program file name SSYSTEM.SII.QUME _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs 0_ 

Priority 90 Alt Priority 95 Threshold 10 Server 0_ 

Server Class QUME Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name _ 

Parameter String clase, qume. Ssvstem.editor.qumeinfo,Ss 


Figure 31.4. Configuration File Record for Editorial qume Process (Sequm) 
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RECEIVER Version 02 (003) 

The receiver process works with the burster process to duplicate and send 
stories between logical systems by using mapgen maps and textgen tables. 


1. Story duplication between logical systems made easier 

Problems: 

Story duplication between logical systems presented the following difficulties: 

1. Certain characters were not translated to counterparts on the receiving system 
when the character sets were different. 

2. Header fields such as guide were lost when the site-definable portion of the 
header structures were different. 

3. Many header fields were unnecessary dead weight during the duplication 
because their values were meaningless when the header was filed on the 
destination system. 

Solution: 

Stories may now be duplicated more reasonably between logical systems using 
mapgen maps and textgen text tables. 

Operation: 

There are three methods for duplicating stories from one system to another. 
These are: (1) No Conversion; (2) Universal Format; (3) and Agreed-Upon For¬ 
mat. (Each is described in detail below). 

The latter two methods require both burster’s and receiver’s startup parame¬ 
ters to include the names of a default map and text table. Given that the defaults 
are specified, information in the system description file determines which method 
is to be used by any particular pair of logical systems. 

1. NO CONVERSION 

No translation of text is performed. This is simply the way duping between 
systems was done previously. It is selected when the sending and receiving 
systems agree on it by having the convert dups bit turned off in each other’s 
system description record (or if the structure does not yet have the convert dups 
field added). 
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The header is copied entirely or in part, depending on whether or not the system 
types match. If they do, the setting of the copy whole hdr bit in the receiving 
system’s system description record is used for the sending system. 

The following is a description of the copy whole header option: 

1. If the systems types (C or E) of the sending and receiving systems are 
different, then the copy whole hdr bit is ignored. Header fields are copied up 
through release status (the end of the common header) and zero-filled from 
that point on, except in a classified header category is set to “G” and ad'type 
to “X”. 

2. For any record in the system description file identifying a system whose type 
matches that of the given receiving system, the copy whole hdr bit informs 
the receiver process whether or not that logical system, local or remote, has a 
similar header to be copied in its entirety when receiving a story from it. For 
example, a large customer with several editorial systems utilizing similar head¬ 
er structures could turn on the bit in the system description record for each of 
those systems in order to preserve fields such as guide, which normally would 
not be copied because it is in the site-definable portion of the header. This 
feature would also be useful for sending takes from a live classified system to 
the site's test classified system, assuming similar header structures. 

3. On an editorial-to-editorial transmission if the bit is not set for the sending 
system then a header received from that system will be copied up to offset 388 
decimal (the end of the fixed portion of the editorial header) and zero-filled from 
that point on. On a classified-to-classified transmission, if the bit is not set the 
header will be treated just as if the take had been received from an editorial 
system, i.e., copied up through release status (the end of the common 
header) and zero-filled from that point on, except that category is set to “G” 
and ad'type to “X”. 

4. Note that this option has no affect on the makeup of the header that is actually 
sent by the burster process, burster will always send the entire header 
after updating certain fields. It is up to the receiver process receiving the story 
to determine how much of the header is to be copied. 

2. UNIVERSAL FORMAT 

This method is useful when the sending and receiving systems have no particular 
agreement as to the format of takes sent between them, perhaps not even 
knowing a thing about each other's header structure or character set. 

It is selected when the convert dups bit is turned on in each other’s system 
description record but there is no map or text table specified in the record. In this 
case, the burster and receiver processes each use the default map and text 
table specified in each of their startup parameter strings. 

This requires the map and table used by the burster process to translate the 
outgoing story into a universal header format and character set. Inversely, the 
map and table used by the receiver process translates the incoming data in the 
universal format into the particular header structure and character set in use on its 
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system. 

Note: The universal header format and character set for story duplication are 
currently being established. Until the format is released, this duplication method 
should not be used. Either of the other two methods should be used. 

3. AGREED-UPON FORMAT 

Maps and text tables are used to translate the header and text into a unique 
predetermined format arbitrarily agreed upon by the sending and receiving 
systems. 

This method is selected when the convert dups bit is turned on and each system 
has the names of the appropriate maps and text tables specified in each other’s 
system description record. The burster process translates the outgoing take 
using the map and table specified in its system description record for the receiving 
system. The receiver process translates the incoming take using the map and 
table specified in the system description record for the sending system. 

An example of a useful application: Site A uses the English language and site B 
uses a different language with many accented characters for which there are no 
equivalents on site A. Takes sent from site B to site A are translated so that 
descriptive strings are substituted for the accented characters. 

Similar to the universal format, the agreed-upon method requires a default map 
and text table to be specified in both burster’s and receiver’s startup parame¬ 
ters. If either a map or text table is specified in the startup parameters, then both 
must be specified. (The same goes for system description records: neither or both 
must be specified). 

Considerations for writing maps: Unlike other processes which invoke put- 
string or getstring to convert stories, burster and receiver invoke the put- 
string and getstring procedures respectively one or more times per story. 
Therefore, any map used by burster or receiver must be capable of being 
executed in a text-only mode (no header fields) so the map can be re-executed 
multiple times for a given story without repeating the header. 

This is accomplished using a flag passed to the map by the process in a Q-struc- 
ture called dup"params. The map references this integer flag as fi.text'only 
and tests it as follows: If the value is zero, then process header fields before 
processing text, otherwise skip the header fields and just process text. 

Another feature affecting the map is the fact that burster’s communication with 
receiver includes an end-of-take indication for every story, so there is no need 
for any such indication in the data formatted by the map. After processing the 
header, all the map has to look for in the text is an end-of-line code to delimit lines 
of text. 

The following is a sample map to work both ways: sending and receiving. It 
assumes that header fields are delimited by the same character used to delimit 
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lines of text, specifically a control character identified as new'line. Note the 
specification of dup'params as the second structure with the header structure 
being the first. 

map dup 

structure header, dup'params 

I 

! Header. 

! 

format story'name^field; 
begin; 

all [0 : *] (-) story^name; 

end new'line; 

format guide'f ield; 
begin; 

all [0 : *] (-) guide; 

end new^line; 

format hdr; 

if not f 1. text~only; 

begin; 

story*name~f ield; 
guide^f ield; 
end; 

» 

! Text (input only) 

f 

format text'line'in; 
begin; 

all [0 : *] -) $1ine; 

control [0 : 1]; 

end; 

formatin text^in; 
begin; 

text*line~in [1 : *] ; 

end; 

! 

! Text (output only) 

t 

format text~l ine^out; 
begin; 

all [0 : *] (- $line; 

new^line; 

end; 

formatout text'out; 
begin; 

text~line~out [0 : *] ; 
end; 

I 

! Main format 
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i 

format dup; 
begin; 
hdr; 
text'in; 
text'out; 
end; 

Considerations for implementation trouble-shooting 

Both the new burster and new receiver are compatible with the old system 
description file; the processes will use values of zero for the new Q-fields in the 
system description record if they are not defined yet. 

The new receiver is compatible with both the old and new burster. 

The old receiver is compatible with the new burster, but if burster tries to 
send map-converted data to an old receiver process, then receiver will reject 
the request and reply to burster with error 22 because it does not support the 
new function code sent by burster indicating that the story requires conversion. 

If burster tries to send map-converted data to an new receiver process but no 
map or text table was specified in receiver’s startup parameters or the receiving 
system’s system description file does not yet have the convert dups Q-field or 
the receiving system’s system description record for the sending system incorrect¬ 
ly indicates that the sending system does not convert duped stories, then receiv¬ 
er will log a message and reject the request with error 22. 

If receiver cannot find a map or text table specified for the particular system 
sending a map-converted story, it will log a message and reject the request with 
error 22. 

If burster cannot find a map or text table specified for the particular system to 
receive a map-converted story, it will log a message and send the story using the 
“no conversion” method. 

putstring and getstring errors reported by burster and receiver indicate 
bugs in maps the same way bugs in maps are reported by other processes. 
However, if putstring errors 17, 18, 21 or 22 occur, or if getstring error 28 
occurs, then the error indicates a bug in the process rather than the map. 

2. RECEIVER now supports a reconfiguration request 

To take note of changes in system description records, maps or text tables, 
receiver now supports a reconfigure request. It is i5. 


3. Use semicolons, not commas, now with RECEIVER 

For consistency, receiver now expects to find semicolons separating its startup 
parameters rather than commas. 
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SECTION 32 

RCVR 

Description: Receiver Process 

Standard Disk File Name(s): SSYSTEM.SI1.RCVR 

Standard Process Name(s): SERCV, SCRCV 

Description 

rcvr is the process which writes a transmitted story or ad into the 
database of the logical system that it had been transmitted to via burster. 
(See burster, Section 11). Receiver optionally supports the use of map- 
gen and textgen tables if data conversion is necessary. 

PSTAT of Editorial RCVR Process 


;pstat SERCV 

Process SERCV (0. 77) was created by: SZEUS 
Program file name is SSYSTEM.SII.RCVR 
Creation ID = 254,255 and process ID = 254.255 
Creator may stop process, and no one has tried. 

Initial priority was 85 and current priority is 85 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 4096 bytes 
File 1 is SO (R/W. Si 

File 2 is SSYSTEM.SYSTEM.SYSTEMS (R. S) 

File 5 is SETW (R/W. Si 
File 6 is SEUPD (R/W, S) 

File 7 is SEBRT (R/W, Si 
File 8 is SEGOD (R/W, S) 

File 9 is SDATA.EDITOR BASKET (R. Si 

File 10 is SDATA. EDITOR.HEADER (R/W, Si, last error was 1 
File 11 is SSYSTEM.EDITOR.DSTGRPS iR/W. S), last error was 1 

Figure 32.1. pstat Information for Editorial rcvr Process (SeRCv) 


Configuration File Record for Editorial RCVR Process 


System E Record type 0_ Process type 20 Record #30 

Process Name SERCV _ 

Program file name SSYSTEM.SII.RCVR _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs 0_ 

Priority 85 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class RCVR Reference name _ 

Home Terminal ____ Rund _ 

Input File Name ___ 

Output File Name ___ 

Parameter String sue: receive ___ 

dev width 


Figure 32.2. Configuration File Record for Editorial Receiver Process (Sercv) 
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Configuration File Parameter String Entries for RCVR 

The parameter string field of the configuration file record for this 
process contains: 

she— the name of the logical system name on which the process is to run 

recejve— the name of the basket in which onward-addressed stories are 
placed pending action by the local burster process 

PSTAT for Advertising RCVR Process 


;pstat SCRCV 

Process $CRCV (0,50) was created by: SZEUS 
Program file name is SSYSTEM.SII.RCVR 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 85 and current priority is 85 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 4096 bytes 
File 1 is SO (R/W, S) 

File 2 is $SYSTEM.SYSTEM.SYSTEMS (R, S) 

File 5 is SCTW (R/W, S) 

File 6 is SCUPD (R/W, S) 

File 7 is SCBRT (R/W, S) 

File 8 is SCG0D (R/W, S) 

File 9 is SSYSTEM.CLASS.BASKET (R, S) 

File 10 is SSYSTEM.CLASS.HEADER (R/W, S) 

File 11 is SSYSTEM.CLASS.DSTGRPS (R/W, S) 

Figure 32.3. pstat Information for Advertising rcvr Process (Sercv) 


Configuration File Record for 
Advertising RCVR Process 


System C Record type 0_ Process type 20 Record #213 

Process Name SCRCV _ 

Program-file name SSYSTEM.SII.RCVR _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs 0_ 

Priority 85 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class RCVR Reference name _ 

Home Terminal_Rund _ 

Input File Name _ 

Output File Name _ 

Parameter String siic;receive _ 

dev width 


Figure 32.4. Configuration File Record for Advertising Receiver Process (Scrcv) 


REQUEST Functions for RCVR 

Here is a list of the various requests that can be given to rcvr: 

REQUEST ACTION 

i5 reconfigure to take note of changes in system de¬ 

scription records, maps or text tables 
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SECTION 33 

ROUTER 

Description: Routing Record Filter Process 
Standard Disk File Name(s): SSYSTEM.SII.ROUTER 
Standard Process Name(s): SEROT 


Description 

router is a zeus server process which acts as a cache for routing 
records used by the insave processes. (See the Input Spooling System 
Manual [S55-033] for a description of the insave process.) Its primary 
purpose is to minimize disk access while maximizing the number of rec¬ 
ords that an insave process can use for routing a story. The insave 
processes requests routing records by sending the selection criteria de¬ 
rived from the story being processed to router, router takes the selec¬ 
tion criteria and filters the routing records based on the line name, 
selection criteria and time. The filtered records are then returned to the 
requesting insave process after being stripped of the no longer useful 
filtering information such as time and selection values. 

PSTAT of Editorial ROUTER Process 


;pstat SEROT 

Process SEROT 1 O. 8 I) was created by: SZEUS 
Program file name is SSYSTEM.SII.ROUTER 
Creation ID = 254,255 and process ID = 254.255 
Creator may stop process, and no one has tried. 

Initial priority was 101 and current priority is 101 

File 0 is SRECEIVE iR/W, SI 

Request 1 is f^E AD UPDATE for 2048 bytes 

File 1 is SO iW. Si 

File 4 is SSYSTEM. EDITOR. INROUTER iR. S) , last error w'as 1 
File 5 is SSYSTEM.EDITOR.INROUTER IR, S) 

Figure 33.1. pstat Information for Editorial router Process (Serot) 
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Configuration File Record for 
Editorial ROUTER Process 


System E Record type 0_ Process type 38 Record #67 

Process Name SEROT _ 

Program file name $SYSTEM.SII.ROUTER _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs -1 

Priority 101 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class ROUTER Reference name _ 

Home Terminal ___ Rund _ 

Input File Name __ 

Output File Name ___ 

Parameter String clase; 20 _ _ _ 


Figure 33.2. Configuration File Record Editorial router Process (Serot) 



Configuration File Parameter String Entries for ROUTER 

The parameter string field of the configuration file record for this 
process contains the following: 


Logical system name, (sue) 


Maximum lines. This is the maximum number of input lines (optional, 
defaults to 20). This parameter assigns space to the line control table. 
Unused lines take away space used to store routing records, router 
returns error 44 to INSAVE when this limit is exceeded. 


REQUEST Functions for ROUTER 


Here is a list of the various requests that can be given to router: 

REQUEST ACTION 

i0 return status to requestor (see “Status Report,” be¬ 


low) 

il, (line name) update routing records by clearing cache (all of 

cache is cleared if no line name is supplied—see 
“Reconfigure Function," below) 

i2 stop when pending request is finished (see “Stop 

Function,” below) 
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• Status Report 

The status report returned for “request io" is illustrated (with comment 
text added) in Figure 33.3 


struct .stats; 


begin 


dbl select A requests; 

initial select requests 

int totarspace; 

total words in cache 

int free'space; 

unused words in free list 

dbl totaTreads; 

cache + disk reads 

dbl cache^reads; 

reads from cache 

dbl disk'reads; 

reads from disk 

dbl line'records; 

total of records in file for requested line 

dbl extraMisk'reads; 

extra disk accesses beyond records in file 

int free A space A pc; 

% free space (free*100/total) 

int cache A hit A pc; 

% cache hits (cache*100/cache + disk) 

dbl garbage'collections; 

number of garbage collections (compactions) 

int space‘failures'threshold; 

can compact when above this threshold 

int space A fai lures; 

count of failures getting space since last compaction 


(can wraparound) 

int free'space'threshold; 

words of free space needed before compaction 


unless space A failures is zero (initially & wraparound) 

int dummy [0:2]; 

filler for spacing so request reply lines up 

str descriptions [0: chars A per A line * 

description A lines -1]; ! ascii version of some fields 

end: 



Figure 33.3. router Process Status Report with Comment Text Added 



Reconfigure Function 


Normally the router is reconfigured with command comma i. This 
request function is another alternative, router is very dynamic in read¬ 
ing and storing. A change to a routing record can be read even before the 
reconfigure command is given. 


Stop Function 


This function stops router after the pending requests are finished and 
before another request is received. Note that records may be transferred 
to insave in more that one request. The routing information may be trun¬ 
cated. 


If ROUTER 
basket from 


is not running, insave continues and uses the default routing 
the Input Line Characteristics Record. 
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SECTION 34 

SAVE 

Description: Background Save Process 
Standard Disk File Name(s): SSYSTEM.SII.SAVE 
Standard Process Name(s): SCSVE, SESVE 

Description 

save is a system overseer server process used as a background save 
process for vcontrol. Implied finishing in vcontrol determines whether 
or not to file a story away itself or pass the work on to save. The determi¬ 
nation is based on the size of the story; long stories are passed on to save, 
short stories are saved directly by vcontrol. save uses textr to read 
from the text file, vcontrol to get changed text, and updateh or 
cupdateh to update the story or ad header once the new story or ad is 
completely stored in the text file. 

PSTAT of Advertising SAVE Process 


;pstat SCSVE 

Process SCSVE (1,51 & 0,60) was created by: SCGOD 
Program file name is SSYSTEM.SII.CUPDATEH 
Creation ID = 254,255 and process ID = 254.255 
Creator may stop process, and no one has tried. 

Initial priority was 150 and current priority is 150 

File 

File 
File 
File 
File 
File 
File 
File 
File 
File 
File 
File 
File 
File 
File 
File 
File 
File 
File 
File 
File 
File 
File 

Figure 34.1. pstat Information for Advertising save Process (Scsve) 


0 is $ RECEIVE (R/W, S) * 

Request 1 is READUPDATE for 86 bytes 

1 is SO (R/W, S) 

2 is SF514 (R/W, S) 

3 is SF104 (R/W. S) 

6 is SCTW tR/W, S) 

7 is SCMSG (R/W. Si 

8 is SCFIO IR/W, S) 

9 is SCBRT (R/W. S) 

10 is SCRCK (R/W. Si 

11 is SSYSTEM.CLASS.DUMPITEM (R/W. S) 

12 is SCTR IR/W. S) 

13 is SSYSTEM.CLASS.HEADER (R/W. S) 

14 is SSYSTEM.CLASS.CLR (R/W. Si 

15 is SSYSTEM.CLASS.SALES (R/W. S) 

16 is SSYSTEM. CLASS.PAYMENTS (R/W. Si 

17 is SCFIL (R/W. Si 

18 is SCLIN (R/W. Si 

19 is SSYSTEM.CLASS.CREDIT (R. Si. last error was 1 

20 is SSYSTEM.CLASS.CLASSC (R. Si 

21 is SSYSTEM.CLASS.ADTYPEC (R. S) 

22 is SDATA.CLASS.CONTROL (R/W. S) 

23 is SDATA. SYSDATA.RESPONSE (R. Si 

24 is SSYSTEM.CLASS.CLDEPT (R. Si 
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File 25 is $SYSTEM.CLASS.SEQUENCE (R, S) 

File 26 is SSYSTEM. CLASS.BASKETGP (R, S) 

File 27 is SSYSTEM.CLASS.BASKET (R, S) 

File 28 is SSYSTEM.CLASS.DESK (R, S) 

File 29 is SDATA.CLASS.QEXTRACT (R, S) 

File 30 is SDATA.CLASS.PUBGROUP (R, S) 

File 32 is SDATA.CLASS.EXTRA CTO (R/W, S) _ 

Figure 34.1. pstat Information for Advertising save Process (Scsve) (concluded) 



Configuration File Record for 
Advertising SAVE Process 


System C Record type 0_ Process type 3_ Record #113 

Process Name SCSVE _ 

Program file name SSYSTEM.SII.CUPDATEH _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs -1 

Priority 150 Alt Priority 110 Threshold 10 Server 0_ 

Server Class SAVE Reference name _ 

Home Terminal ___ Rund _ 

Input File Name __-_ 

Output File Name ___ 

Parameter String CLASC;S; ___ 


Figure 34.2. Configuration File Record for Advertising save Process (Scsve) 


Configuration File Parameter String Entries for Advertising 
SAVE Process 

The parameter string field of the configuration file record for this 
process is the same as the parameter string field for the cupdateh 
process. Please see Section 14. 
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PSTAT of Editorial SAVE Process 


;pstat Sesve 

Process SESVE (0, 69) was created bv: SEGOD 
Program file name is SSYSTEM.SII.SAVE 
Creation ID = 254,255 and process ID = 254.255 
Creator may stop process, and no one has tried. 

Initial priority was 100 and current priority is 100 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 86 bytes 
File 1 is $0 (R/W. S) 

File 2 is SF513 (R/W, S) 

File 3 is SF505 (R/W, S) 

File 4 is SETRl (R/W, S) 

File 5 is SETW (R/W, S) 

File 6 is SEUPD (R/W, S) 

File 7 is SF314 (R/W, S) 

File 8 is SSEH (R/W, S) 

File 9 is SF104 (R/W. S) 

File 10 is SF103 (R/W, S) 

File 11 is SF507 (R/W, S) 

File 12 is SF203 (R/W, S) 

File 13 is SF214 (R/W, S) 

File 14 is SF512 (R/W, S) 

Figure 34.3. pstat Information for Editorial save Process (Sesve) 

Configuration File Record for Editorial SAVE Process 


System E Record type 0_ Process type 3_ Record #117 

Process Name SESVE _ 

Program file name SSYSTEM.SII.SAVE _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs -1 

Priority 100 Alt Priority 110 Threshold 10 Server 1_ 

Server Class SAVE Reference name _ 

Home Terminal _ Rund 

Input File Name _ 

Output File Name __ 

Parameter String clase _ 


Figure 34.4. Configuration File Record for Editorial save Process (Sesve) 


Configuration File Parameter String Entries for SESVE 

The parameter string field of the configuration file record for this 
process contains the logical system name (clase). 

REQUEST Functions for CSVE 

Listed below are the requests that can be given to csve. 

REQUEST ACTION 

i22 Die gracefully. 
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SECTION 35 

SCHED 

Description: Program Scheduler 

Standard Disk File Name(s): SSYSTEM.Sll.SCHED 

Standard Process Name(s): SSCHD 


Description 

sched reads from a database the names of programs to be run at 
particular times, creates them, sends them startup messages, and waits 
for them to terminate. It is used in conjunction with schedset, which 
maintains the database, allowing users to add new programs and times. 
See the description of schedset in Section 87. 

PSTAT of SCHED Process 


;pstat SSCHD 

Process SSCHD (1,45 & 0,46) was created by: SZEUS 
Program file name is SSYSTEM.SII.SCHED 
Creation ID = 255,253 and process ID = 255,253 
Creator may stop process, and no one has tried. 
Waiting for LREQ 
Will time out in 22.17 seconds 

Initial priority was 145 and current priority is 145 
S = 004004 P = 074635 E = 002427 L = 004003 
LISTEN LCB’s reserved: 0. LINK LCB's reserved: 0 
LISTEN LCB's in use: 0. LINK LCB’s in use: 0 
I/O was last done to file 0, last error was 40 
File 0 is $RECEIVE (R/W, S) 

Request 1 is READ for 100 bytes 
File 1 is SO (R/W, S) 

File 4 is SSYSTEM.SCHED.PROGRAMS (R/W, S) 

File 5 is SSYSTEM.SCHED.TIMES (R/W, S) 


Figure 35.1. pstat Information for sched Process (Sschd) 




Configuration File Record for SCHED Process 


System _ Record type 0_ Process type 29_ Record #254 

Process Name SSCHD _ 

Program file name SSYSTEM.SII.SCHED _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs -1 

Priority 145 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class SCHED Reference name _ 

Home Terminal _ Rund 

Input File Name ___ 

Output File Name __ 

Parameter String clase,super.sched.SCHED _ 


Figure 35.2. Configuration File Record sched Process (Sschd) 
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Configuration File Parameter String Entries for SCHED 

The parameter string field of the configuration file record for this 
process contains the following: 

Logical system name, (sue) 

Tandem user. The Tandem user that $schd will run as. 

Password. The current password for the given Tandem user. 


\ 
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SECTION 36 

SPELL 

Description: Spell Check Process 

Standard Disk File Name(s): SSYSTEM.SII.SPELL 

Standard Process Name(s): SCSPL, SESPL 


Description 

The spell process is a system overseer server process. It accepts 
requests to check the spelling in stories and ads. It can insert a summary 
of spelling errors into the story or ad or make a list of them available for 
editing with the utility spedit (see the System/55 Editorial Manager’s 
Manual [ S55-010]). 

PSTAT of Advertising SPELL Process 


;pstat SCSPL 

Process SCSPL (0,51) was created by: SCGOD 
Program file name is SSYSTEM.SII.SPELL 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 50 and current priority is 50 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 86 bytes 
File 1 is SO (R/W, S) 

File 2 is SDATA.DICT.MASTER (R, S) 

File 3 is $SYSTEM.DICT.SPELLH (R/W, S) 

File 4 is SSYSTEM.CLASS.HEADER (R/W, S) 

File 5 is SCTR (R/W. S) 

File 6 is $CTW (R/W, S) 

File 7 is SCUPD (R/W, S) 

File 8 is SSYSTEM.DICT.SPELLW (R/W, S) 

File 9 is SSYSTEM.DICT.SPELLTAB (R/W. S) 


Figure 36.1. pstat Information for Advertising spell Process (Scspl) 
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Configuration File Record for 
Advertising SPELL Process 


System C Record type 0_ Process type 3_ Record #21 

Process Name SCSPL _ 

Program file name $SYSTEM,SII.SPELL _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs 0_ 

Priority 50 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class SPELL Reference name _ 

Home Terminal __ Rund _ 

Input File Name ___ 

Output File Name ____ 

Parameter String clasc;Sdata.PICT.MASTER;Ssvstem.PICT.PREFIX; 
Ssvstem, PICT. SUFFIX; Ssvstem. PICT, spellh; Ssystem. PICT, spellw; ... 
Ssvstem,PICT.SPELLTAB 

Figure 36.2. Configuration File Record for Advertising spell Process (Scspl) 


Configuration File Parameter String Entries for SPELL 

The parameter string field of the configuration file record for this 
process contains: 

clasc —The name of the logical system on which the process is to run. 
$data.dict.master —the master dictionary used for the logical system 
Ssvstem.dict.prefix —the table of word prefixes. 

Ssystem.dict.suffix —the table of word suffixes. 

Ssystem.dict.spellh —one record/story with control information for 
SPEDIT 

Ssystem.dict.spellw— one record/error word of a story for spedit 

Ssystem.dict.spelltab —words of previous stories (past experience) to 
save access to dictionary (loaded when spell starts). 

PSTAT of Editorial SPELL Process 


;pstat $ESPL 

Process $ESPL (0,67) was created by: $EG0D 
Program file name is SSYSTEM.SII.SPELL 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 50 and current priority is 50 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 86 bytes 
File 1 is $0 (R/W, S) 

File 2 is SDATA.DICT.MASTER (R, S), last error was 1 
File 3 is $SYSTEM.DICT.SPELLH (R/W, S) 

File 4 is SDATA.EDITOR.HEADER (R/W, S) 

File 5 is SETRl (R/W, S) 

File 6 is SETW (R/W, S) 

File 7 is SEUPD (R/W, S) 

File 8 is SSYSTEM.DICT.SPELLW (R/W, S) 

File 9 is $SYSTEM.DICT.SPELLTAB (R/W, S) 

Figure 36.3. pstat Information for Editorial spell Process (Sespl) 
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Configuration File Record for 
Editorial SPELL Process 


SPELL 


System E Record type 0_ Process type 3_ Record #322 

Process Name SESPL _ 

Program file name $SYSTEM.SII.SPELL _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs 0_ 

Priority 50 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class SPELL Reference name _ 

Home Terminal _ Rund __ 

Input File Name _ 

Output File Name _ 

Parameter String clase;Sdata.PICT.MASTER:Ssvstem. PICT. PREFIX; 
Ssvstem. PICT.SUFFIX;Ssystem.PICT.spellh;Ssvstem. PICT, spellw; 

Ssvstem.PICT.SPELLTAB 

Figure 36.4. Configuration File Record for Editorial spell Process (Sespl) 


REQUEST Functions for ESPL and CSPEL 

Listed below are the requests that can be given to espl and cspel. 

REQUEST ACTION 

-1 Load hit list into recovery file. 
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SECTION 37 

TEXTR 

Description: Text Read Process 

Standard Disk File Name(s): SSYSTEM.Sil.TEXTR 

Standard Process Name(s): SCTR, $ETR 

Description 

textr is a server process that is used by any process requiring data 
from the text file. The story header file is used to index the text file, 
providing the starting address for subsequent textr requests, textr pro¬ 
cesses requests to read a specific record from the text file, replying with 
the data located at that address in the text file, textr requires some 
interaction with textw at startup time to determine the status of the text 
files. More than one textr process can be run on a logical system. 

PSTAT of Advertising TEXTR Process 


pstat SCTR 

Process SCTR (1,50) was created by: SZEUS 
Program file name is $SYSTEM.SII.TEXTR 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 155 and current priority is 155 

File 0 is $RECEIVE (R/W, S) 

File 2 is SO <R, S) 

File 3 is $SYSTEM.CLASS.TEXTF (R, S) 

File 4 is SDATA.CLASS.TEXTF2 (R. S) 

Figure 37.1. pstat Information for Advertising textr Process (Sctr) 


Configuration File Record for 
Advertising TEXTR Process 


System C Record type 0_ Process type 6_ Record #65 

Process Name SCTR _ 

Program file name SSYSTEM.SII.TEXTR _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs -1 

Priority 155 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class TEXTR Reference name _ 

Home Terminal __ Rund _ 

Input File Name ___ 

Output File Name ______ 

Parameter String c ___ 


Figure 37.2. Configuration File Record for Advertising textr Process (Sctr) 
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PSTAT of Editorial TEXTR Process 


;pstat $ETR 

Process $ETR (0,68) was created by: $ZEUS 
Program file name is $SYSTEM.SII.TEXTR 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 155 and current priority is 155 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 2048 bytes 
File 2 is $0 (R, S) 

File 3 is $SYSTEM.EDITOR.TEXTF (R, S) 

Figure 37.3. pstat information for Editorial textr Process ($etr) 



Configuration File Record for 
Editorial TEXTR Process 


System E Record type 0_ Process type 6_ Record #65 

Process Name $ETR _ 

Program file name SSYSTEM.SII.TEXTR _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs -1 

Priority 155 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class TEXTR Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name _ 

Parameter String e_ 


Figure 37.4. Configuration File Record for Editorial textr Process ($etr) 
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SECTION 38 

TEXTW 

Description: Text Write Process 

Standard Disk File Name(s): SSYSTEM.Sll.TEXTW 

Standard Process Name(s): SCTW, SETW 

Description 

textw is a NonStop server process which must be used by all process¬ 
es to add, delete, or change text file records. No other process in the 
system is capable of writing to the text file. Besides acting on requests to 
write data to the text file, textw also acts on requests to change the state 
of a story from “in use” to either “saved” or “audited” to create “oops” or 
“audit” copies of stories. Similarly, a story can be recovered (made “in use” 
again) by submitting requests to textw. This function is employed when a 
user wants to recover the previous version of a story, textw maintains all 
of the chains that are run through the text file. There are chains connecting 
all records of stories and there are chains of blank records. Only one 
textw process can be run on a logical system. 

PSTAT of Advertising TEXTW Process 


;pstat SCTW 

Process SCTW (0,44 & 1,56) was created by: SZEUS 
Program file name is SSYSTEM.SII.TEXTW 
Creation ID = 254.255 and process ID = 254.255 
Creator may stop process, and no one has tried. 

Initial priority was 160 and current priority is 160 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 2048 bytes 
File 2 is SO (R. Si 

File 3 is SSYSTEM.CLASS.TEXTF (R/W. P) 

File 4 is SDATA.CLASS.TEXTF2 (R/W. P) 

Figure 38.1. pstat Information for Advertising textw Process (Sctw) 
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Configuration File Record for 
Advertising TEXTW Process 


System C Record type 0_ Process type 5_ Record #62 

Process Name SCTW _ 

Program file name $SYSTEM.SII.TEXTW _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs -1 

Priority 160 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class TEXTW Reference name _ 

Home Terminal _ Rund _ 

Input File Name __ 

Output File Name _ 

Parameter String c_ 


Figure 38.2. Configuration File Record for Advertising textw Process ($ctw) 


Configuration File Parameter String Entries for TEXTW 

The parameter string field of the configuration file record for this 

process may contain: 

(system id)— system identifier letter (c, e) 

(oops time)—the number of seconds to try to keep oops copies (default 24 
hours if not specified) 

(check interval)—the number of seconds between percentage-full checks 
(default 3600 or hourly). If a text file is more than n% full, a message 
is output every check interval. 

(full threshold)—the percentage of file full to type messages (default 85) 

(allocation message)—the number of check intervals between text file 
extent allocation failure messages. The allocation is attempted every 
check interval but a message is only typed every n check intervals. 
The default is 6. 

PSTAT of Editorial TEXTW Process 


;pstat $ETW 

Process SETW (0,66 & 1,72) was created by: SZEUS 
Program file name is $SYSTEM.SII.TEXTW 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 160 and current priority is 160 

File 0 is $RECEIVE fR/W, S) 

Request 1 is READUPDATE for 2048 bytes 
File 2 is $0 (R, S) 

File 3 is SSYSTEM.EDITOR.TEXTF (R/W. P) 

Figure 38.3. pstat Information for Editorial textw Process (Setw) 
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Configuration File Record for 
Editorial TEXTW Process 


System E Record type 0_ Process type 5_ Record 62 

Process Name SETW _ 

Program file name $SYSTEM.SII.TEXTW _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs -1 

Priority 160 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class TEXTW Reference name _ 

Home Terminal _ Rund _ 

Input File Name __ 

Output File Name _ 

Parameter String c__ 


Figure 38.4. Configuration File Record for Editorial textw Process ($etw) 

REQUEST Functions for ETW and CTW 

Listed below are the requests that can be given to etw and ctw. 

REQUEST ACTION 

i16 Die nicely (in between processing of stories so 

stranded text records are not left in the text file. 


38.3 















Sll Processes 


This page intentionally left blank. 



Sll Processes 


VPUTGET 


SECTION 39 

VPUTGET 

Description: VDT Put/Get Process 

Standard Disk File Name(s): SSYSTEM.SII.VPUTGET 

Standard Process Name(s): SCPVT, SCVGT, SEVPT, SEVGT, SEVPM, 

SCVPM 


Description 

vputget is a server process, primarily used by vcontrol to format and 
validate data records through forms. When vcontrol needs a record 
converted to display codes for the vdt, the binary record along with the 
name of the form desired is sent to vputget, which replies with the display 
codes necessary to write the formatted record to the vdt. When a form is 
completed by the user, vcontrol sends the original binary record along 
with data received from the vdt to vputget, which performs syntax and 
programmatic checks on the user-entered information and converts the 
ascii data back into the appropriate record format. 


When an existing form is changed (using fgen), vputget is notified of 
the change so that subsequent requests for the specified form will immedi¬ 
ately utilize the new definition. 

vcontrol uses another server process, vprompt, to format and vali¬ 
date vdt prompts. 


PSTAT of Advertising VGET Process 


;pstat SCVGT 

Process SCVGT (1.52) was created by: SZEUS 
Program file name is SSYSTEM.SII.VPUTGET 
Creation ID = 254.255 and process ID = 254.255 
Creator may stop process, and no one has tried. 

Initial priority was 150 and current priority is 150 

File 0 is SRECEIVE (R/W. S) 

Request 1 is READUPDATE for 2092 bytes 
File 1 is SO (R/W. Si 
File 5 is SCFI0 (R W. Si 
File 6 is SCFIL (R/W. Si 
File 7 is SSYSTEM.CLASS.FMSG (R. S) 

File 8 is SSYSTEM.CLASS.HEADER (R. Si 
File 9 is SSYSTEM.CLASS.CLR (R/W. Si 
File 10 is SSYSTEM.CLASS.CLDEPT (R. Si 
File 11 is SCUPD (R/W. Si 
File 12 is SCLIN (R/W. Si 
File 13 is SCRCK (R/W. Si 


Figure 39.1. pstat Information for Advertising vget Process (Scvgt) 
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Configuration File Record for 
Advertising VGET Process 


System C Record type 0_ Process type 8_ Record #69 

Process Name $CVGT _ 

Program file name $SYSTEM.SII.VPUTGET _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs -1 

Priority 150 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class VGET Reference name _ 

Home Terminal._ Rund _ 

Input File Name _ 

Output File Name _*_ 

Parameter String clasc _ 


Figure 39.2. Configuration File Record for Advertising vget Process (Scvgt) 


Configuration File Parameter String Entries for VPUT and 
VGET 

The parameter string field of the configuration file record for this 
process contains the logical system name (sue). 

PSTAT of Editorial VGET Process 


;pstat SEVGT 

Process SEVGT (0,76) was created by: SZEUS 
Program file name is SSYSTEM.SII.VPUTGET 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 150 and current priority is 150 

File 0 is $RECEIVE (R/W, S) 

Request 1 is READUPDATE for 2092 bytes 
File 1 is $0 (R/W, S) 

File 2 is SSYSTEM.Q.QFIELD (R/W, S) 

File 5 is SEFIO (R/W, S) 

File 6 is SEFIL (R/W, S) 

File 7 is SSYSTEM.EDITOR.FMSG (R, S) 

File 8 is SDATA.EDITOR.HEADER (R, S) 

Figure 39.3. pstat Information for Editorial vget Process (Sevgt) 
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Configuration File Record for Editorial VGET Process 


System E Record type 0_ Process type 17 Record #96 

Process Name SEVGT _ 

Program file name SSYSTEM.SII.VPUTGET _ 

Primary CPU 1_ Alternate CPU 0_ Available CPUs -1 

Priority 150 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class VGET Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name _ 

Parameter String clase _ 


Figure 39.4. Configuration File Record for Editorial vget Process (Sevgt) 

PSTAT of Editorial VPUT Process 


pstat SEVPT 

Process SEVPT (0,7*0) was created by: SZEUS 
Program file name is SSYSTEM.SII.VPUTGET 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 150 and current priority is 150 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 2092 bytes 
File 1 is SO (R/W, S) 

File 5 is SEFIO (R/W. S) 

File 6 is SEFIL (R/W, S) 

File 7 is SSYSTEM.EDITOR.FMSG (R, S) 

File 8 is SDATA.EDITOR.HEADER iR. S) % 

Figure 39.5. pstat Information for Editorial vput Process (Sevpt) 


Configuration File Record for Editorial VPUT Process 


System E Record type 0_ Process type 8_ Record #106 

Process Name SEVPT _ 

Program file name SSYSTEM.SII.VPUTGET _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs -1 

Priority 150 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class VPUT Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name __ 

Parameter String clase _ 


Figure 39.6. Configuration File Record for Editorial vput Process (Sevpt) 


REQUEST Functions for VPUT 

Listed below are the requests that can be given to vput. 

REQUEST ACTION 

i9 Close files. 
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SECTION 40 

VSTARTUP 

Description: VCONTROL Startup Process 
Standard Disk File Name(s): SSYSTEM.SII.VSTARTUP 
Standard Process Name(s): SCONF 

Description 

vstart is a server process to provide startup information to vcontrol 
processes. It performs nearly all of the disk accesses necessary during 
startup or during a sign-on and keeps the information in memory to be 
furnished to requestors on demand. The primary purpose of vstart is to 
remember file names and process names looked up in the config file, but it 
also keeps system description records, header Q-field offsets, and other 
items. 

vstartup is required by vcontrol version 028 (ooo). Any version of 
vcontrol whose revision level is 028 or higher will not run unless the 
vstartup process is running. In order for its requestors to be able to 
access it, vstart must be run with the hard-coded process name “Sconf.” 
It is normally run from the configuration file by Szeus as a system-indepen¬ 
dent utility (no system id; Process Type 2). Sconf has no startup parame¬ 
ters. 


PSTAT of VSTARTUP Process 


;pstat SCONF 

Process SCONF (1.40) was created by: SZEUS 
Program file name is SSYSTEM.SII.VSTARTUP 
Creation ID = 254.255 and process ID = 254.255 
Creator may stop process, and no one has tried. 

Initial priority was 140 and current priority is 140 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 272 bytes 
File 1 is $SYSTEM.SYSTEM.SYSTEMS (R. Si 

File 2 is SSYSTEM.SYSDATA.CONFIG (R. S). last error was 1 


Figure 40. 1. pstat Information for vstartup Process (Sconf) 
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Configuration File Record for VSTARTUP Process 


System _ Record type 0_ Process type 2_ Record #666 

Process Name SCONF _ 

Program file name SSYSTEM.SII.VSTARTUP _ 

Primary CPU 2_ Alternate CPU 0_ Available CPUs 0_ 

Priority 140 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class FILIP Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name _ 

Parameter String ___ 


Figure 40.2. Configuration File Record for vstartup Process (Sconf) 


REQUEST Functions for SCONF 

Here is a list of the various requests that can be given to Sconf: 

REQUEST ACTION 

11 reconfigure Sconf 

12 stop Sconf 

« 

When Requests Are Necessary 

Below is a list of items Sconf keeps in memory. If any of these items are 
changed on any local logical system, Sconf must be reconfigured with the 
“il” request function. (The process can be stopped using the “i2” request 
function, but this should not be necessary since the “il” function initializes 
everything the process keeps in memory.) 

• Configuration records 

• System description records for local logical systems 

• Header structure Q-fieid offsets 

• Name of the user profile structure 

• Names of logical h & j devices 

• Header extract file information 

• just fields and save fields defined in the o-extract file 

• Transmission priorities 
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SECTION 41 

VSTAT 

Description: VDT Statistics Process 

Standard Disk File Name(s): SSYSTEM.SII.VSTAT 

Standard Process Name(s): SCST, SEST 

Description 

vstat is a dynamic vdt statistics collector. Unlike gstat, it maintains no 
disk files and keeps no record of user name, terminal process, or prompt 
time. See “DSTAT Utility, Section 68" for information about the statistics 
collected by vstat. 

PSTAT of Editorial VSTAT Process 


;pstat $est 

Process SESTA (0.96) was created by: SZEUS 
Program file name is SSYSTEM.SII.VSTAT 
Creation ID = 254,255 and process ID = 254,255 
Creator may stop process, and no one has tried. 

Initial priority was 145 and current priority is 145 

File 0 is SRECEIVE (R/W, S) 

Request 1 is READUPDATE for 64 bytes 
File 1 is SO (R/W, S) 

Figure 41.1. pstat Information for Editorial vstat Process (Sest) 


Configuration File Record for 
Editorial VSTAT Process 


System E Record type 0_ Process type 2_ Record #234 

Process Name SEST _ 

Program file name SSYSTEM.SII.VSTAT _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs -1 

Priority 145 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class STAT Reference name _ 

Home Terminal _ Rund 

Input File Name _ 

Output File Name _ 

Parameter String _ 


Figure 41.2. Configuration File Record for Editorial vstat Process (Sest) 
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System C Record type 255 Process type 2_ Record #234 

Process Name $CST _ 

Program file name SSYSTEM.SII.VSTAT _ 

Primary CPU 0_ Alternate CPU 1_ Available CPUs -1 

Priority 145 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class STAT Reference name _ 

Home Terminal _ Rund _ 

Input File Name _ 

Output File Name _ 

Parameter String _ 


Figure 41.3. Configuration File Record for Advertising vstat Process ($cst) 
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SECTION 42 

Database Overview 

Everything that is stored on disk—programs, text, headers, and so 
on—is contained in a file. There are many kinds of disk files. The three 
primary kinds are: 

1. Program files (executable object code) 

2. Data files (text of stories, user profiles, and so on). 

3. System command files (these check system status, for example, and 
are referred to as edit or obey files). 

Only data and system command files may be altered by authorized 
users; program files are maintained by Sll programmers. 

Each file has a name by which it can. be accessed, changed, and 
purged. These names have the following form; \node.$volume.subvol¬ 
ume. diskfile. (See “Naming Conventions” in the Section 3 for a more 
complete explanation of permanent disk file naming conventions.) 

The data files in System/55 are organized in the following fashion: Files 
are on disk, within the files are records, within the records are fields. The 
structure is the data definition describing the type and location of data 
stored in each field of a record. Structures are defined through the Utility q. 
See Index of Record Structures (S55-007) for more information. 

Forms and list provide the users’ view of the data on the terminal screen 
from the editorial or advertising system. When you display a form on your 
vdt you see selected fields from one record in a file. When you display a 
list on your vdt you see selected fields from many records. Figure 41.1 
shows the relationships of files, records, and fields. 
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Figure 42.1. Files, Records, and Fields. 

There are two kinds of data files: 

1. Unstructured data files have blocks of data (binary information) without 
a key for access and no associated structure. 

2. Structured Data files have records and an associated structure. 

There are three kinds of structured files: 

• Key-sequenced (indexed) files—in key-sequenced files, records are 
stored in ascending order according to the primary key field within the 
record. The records can be accessed directly by key. 

• Entry-sequenced files—In entry-sequenced file organizations, records 
are stored in the same order in which they are entered into the system. 
The primary key is the record's logical address. 

• Relative files—In relative file organizations, records are stored by their 
position within the file. The primary key is the number of the record’s 
relative position in the file. 

Relational Database 

Tandem implements a relational database through its enscribe data¬ 
base record manager. This supports the use of alternate key files that 
provide an alternate index to the primary file, enscribe updates all associ¬ 
ated alternate key records at the time any primary record is changed. The 
major benefit is that data can be displayed in many different sequences 
without having to sort it for each sequence. For example, stories in editorial 
can be listed by author, by topic, or by keyword by different users without 
having to sort the data in the header file each time a list is displayed. The 
path field of the index and directory prompts in the Editorial and Advertis¬ 
ing systems is the field that specifies use of a particular alternate key. 
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Data File Descriptions 


The System/55 data files are described in the following section. For 
more information on specific data files, see the Index of Record Structures 
(S55-007). 
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SECTION 43 

Configuration File 

Description: Configuration File 

Standard Disk File Name: SSYSTEM.SYSDATA.CONFIG 
Standard List Name: CONFIG 
Config Record Type: 0 

When System/55 is cold started, a process called Szooo (a command 
interpreter) is started. Szooo then starts the super process (Szeus), which 
reads a data file and begins starting other processes. 

This data file, called the configuration file, is stored on disk in Ssys- 

TEM.SYSDATA.CONFIG. 

The configuration file contains a record of all of the processes on the 
system that run under Szeus and the two system overseers, Segod and 
Scgod. It lists all software configuration information: process names, priori¬ 
ties, and so on. A typical configuration file record is illustrated in Figure 
43.1. See "Fields in the Configuration File Record” for an explanation of 
the fields in the form. 

The configuration file serves three purposes: 

1. It allows the system flexibility in naming of data files. 

2. It provides a method of dynamically allocating resources. (Szeus allo¬ 
cates system resources when it receives a request from a process for 
the name of a specific process in a given class. Szeus locates the 
process that is least busy and replies to the requestor with its name.) 

3. It makes restarting the system more convenient since all of the system 
processes are described in the configuration file. Starting the system 
requires that only Szeus be manually executed. It then looks through 
the configuration file and creates all the remaining processes. 


System E Record Type 0_ 

Process Name SF105 


Process type 4_ 


Record #999 


0 


Program File Name SSYSTEM.SII.ECONTROL 

Primary CPU 3_ Alternate CPU 0_ Available CPUs _ 

Priority 140 Alt Priority 0_ Threshold 0_ Server 0_ 

Server Class _ Reference Name _ 

Home Terminal 


Input File Name 
Output File Name 
Parameter String 


SOSP 

SF1.#L05 


Rund 


SFl . #L05 


E;SPATA.VPEND.F105; : :SF1. #R05 


Figure 43.1 . Configuration File Record for Terminal Sfi 05 


At cold start time. Szeus starts processes by reading the record for each 
process in the configuration file and constructing run lines. 

For example, using the parameters in the configuration file record for 
process Sfios (Figure 43.1), Szeus would issue the following run com¬ 
mand: 
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RUN $SYSTEM. SII.ECONTROL / NAME $F105, PRI 140, CPU 3, 

IN $F1.#L05, OUT $F1.#L05, TERM $OSP, NOWAIT / E, 

SDATA.VPEND.F105, , , $F1.#R05. 

Fields in the Configuration File Record 

system—[god'id] The logical subsystem (if any) to which this record 
relates (e = editorial; c = classified). 

record type — [rec'type] Indicates the record type (see Appendix E for 
a list of record types.). 

process type — [proc'type] Identifies the process type for this record 
(see Appendix D for a list of process types). 

record #—Identifies the record number of this record in the file. 

process name — [proc'name] This is the name that will be given to the 
process. Only applies to program files that are to be executed. See 
Appendix C for a list of named processes. 

program file name—[prog'name] The (Svolume.subvolume.filename) of 
the data file. For example, Ssystem.sii.econtrol. 

primary cpu — [cpu] The cpu in which the process will initially be execut¬ 
ed. 

alternate cpu — [alt"cpu] The cpu to which the process will be moved in 
the event of a primary cpu failure. 

available cpus — [avail'cpus] The cpus that are available in any event 
(enter -1 to indicate all cpus; 0 to indicate no cpus). 

priority — [priority] The priority that will be assigned to the process. 

alt priority — [alt'priority] The priority to which the process will be set 
in the event that the queue of outstanding requests to this process 
reaches the threshold limit (see threshold below). 

threshold — [threshold] When the number of requests that are waiting 
to be serviced by this process reaches this number, the alt priority 
will take effect. 

server — [server>ri] When there are multiple server processes in this 
server class, this field is used to assign priorities to requests to them. 

For example, if there are 3 just processes, each will have a separate 
configuration file record specifying the cpu in which it is to run, and, 
through the use of this field, the order in which it is to be used. If the 
three processes (justx, JUSTy, and justz) in cpus 1, 2, and 3, 
respectively, are given priorities of 1, 2, and 3, justx in cpu i will be 
used for the first request and JUSTy in cpu 2 for will be used for the 
second request if justx is still busy, justz in cpu 3 will be used only if 
the overseer process (Segod or Scgod) gets a third request while the 
first two are still busy. 

server class — [class'name] Each named server class in records creat¬ 
ed by this overseer process will be a resource managed by this 
overseer. 

Requests to Segod or Scgod (made when a command is executed 
from the terminal) are instructions to perform a process on a story or 
ad. 
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For example, when you sign on, the vcontrol process will read the 
configuration file using Path “al” (system, record type, process type) 
for record type 0, and process type 6 in order to access a text file read 
process (textr) record. The server class of that record (textr), is 
sent to Szeus which determines which one of the records to use. 
Szeus also determines which textr process is being used by the 
smallest number of users. The one with the least users is the one for 
this vcontrol to use. 

reference name—[ref'name] This can be used to group related config¬ 
uration file records. It is only required for the just processes. (This 
enables the styl compiler to notify each justification process when a 
styl has been changed so the latest version can be used.) 

home terminal—[home'term] The home terminal of the process; where 
messages will be sent in the event it goes into debug. 

rund—[rund'flag] Enter x if the process should go to debug when run. 

input file name—[in'file] The input file for the process. 

output file name—[out'file] The output file of the process. 

parameter string—[params] Optional parameters that may be passed 
to a process upon execution. For example: if a process is used only 
by the editorial system, e would be entered here. 

Paths through the Configuration File 

Six paths are available for listing the records in the configuration file 

([cmd][x]). 

path pn— Process Name—Path pn with no key lists the configuration file 
records in alphabetical order by process name. Key $F302 lists the 
records beginning with the entry for the process with that name. Key 
$F* lists records for processes beginning with Sf. 

path gd —God ID—Path go with key e lists the records for processes that 
are descendants of Segod. Key c lists the records for processes that 
are descendants of Scgod. 

path pt —Process Type—Path pt with no key lists the configuration file 
records in ascending numerical order by process type. Key #3 lists 
records beginning with type 3 processes. Key #3* lists records for 
only type 3 processes. 

path rn — Record Number—Path rn with no key lists the configuration file 
records in ascending numerical order by record number. Key #12 
lists records beginning with record number 12. 

path rt— Record Type—Path rt with no key lists the configuration file 
records in ascending numerical order by record type. Key #7 lists 
records beginning with record type 7. Key #7’ lists only record type 7. 

path al— System, Record Type, Process Type—Path al with no key lists 
the configuration file records sorted by system (alpha), record type 
(ascending), and process type (ascending). 
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SECTION 44 

Header File 

Standard Disk File Name(s): Ssystem.editor.header (editorial); 

Ssystem.class.header (advertising) 

Standard List Name; headers 
Config Record Type: 1 

Description 

The header file contains information about stories and ads on the 
systems; the name of the basket and desk they reside in, the list of users 
who have worked with them, pointers to current and previous versions and 
so on. The header record for a story is locked (through the system over¬ 
seer) when a user edits a story and unlocked when the editing session is 
complete. 
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SECTION 45 

User File 


Standard Disk File Name(s): Ssystem.editor.users (editorial); 

Ssystem.class.users (advertising) 

Standard List Name: users 
Config Record Type: 3 

Description 

The user file for each system contains information about the users in 
that system: passwords, defaults, authorities, Tandem user name, Tan¬ 
dem password, and all other user-specific information. The user file entry 
for a given user is read in by the vcontrol process when the user signs 
on, retained in memory, and updated when the user signs off. 
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SECTION 46 

Basket File 


Standard Disk File Name(s): Ssystem.editor.basket (editorial); 

Ssystem.class.basket (advertising) 

Standard List Name: baskets 
Config Record Type: 5 


Description 

The basket file for each system contains the information about each 
basket in that system. It contains the factors used in computing story 
* expiration dates, and the sorting method to be used for items in the basket. 
Baskets are locked (through the system overseer) only when the definition 
is being updated by a user. 
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SECTION 47 

Desk File 


Desk File 

Standard Disk File Name(s): Ssystem.editor.desk (editorial); 

Ssystem.class.desk (advertising) 

Standard List Name: desks 
Config Record Type: 4 

Description 

The desk file for each system contains information about each desk in 
that system. It contains the sorting method to be used for items in the desk. 
It does not contain information affecting story expiration dates. 
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SECTION 48 

Message File 

Standard Disk File Name(s): Ssystem.editor.msgfile (editorial); 

Ssystem.class, msgfile (advertising) 

Standard List Name: n/a 
Config Record Type: 7 

Description 

The message file is maintained by the message process. It contains all 
messages to all users in a system. The message process writes messages 
to the message file and the vcontrol process reads and deletes mes¬ 
sages from it as the user gets a list of his or her messages and acknowl¬ 
edges them. The message file contains the text of the message, the name 
of the user who sent the message, the name of the user to whom the 
message was sent, and when the message was sent. The message file is 
self-purging; unacknowledged messages older than three weeks are auto¬ 
matically purged. 


\ 
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SECTION 49 

Save String File 

Standard Disk File Name(s): Ssystem.editor.strings (editorial); 

Ssystem.class.strings (advertising) 

Standard List Name: n/a 
Config Record Type: 10 

Description 

The save string file is maintained by vcontrol. It contains users' save 
and recall strings. A given string for a particular user may contain up to 200 
individual records, each of which can hold 1,000 characters. The save 
string file is also where udks and sdks are stored by the glossary definition 
process, gloss. 
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SECTION 50 

Text File 

Standard Disk File Name(s): Ssystem.editor.textf (editorial); 

Ssystem.class.textf (advertising) 

Standard List Name: n/a 
Config Record Type: 2 

Description 

The text file is maintained by a text write process (textw). textw opens 
the file “protected” so that all other processes must open it read only. Thus, 
the text file cannot be modified except by the textw process controlling it. 
This is why, when one user is editing a story or ad, others may only get the 
text in read-only mode. 

A given block of text file storage falls into one of four categories. Blocks 
that have never been used for text storage are called virgin blocks. Text 
blocks that were in use but are now deleted are chained together into what 
is called the front chain. Records that were in use but are now part of an 
oops copy are kept in another chain called the rear chain. Records that are 
currently in use are pointed to by the header record for a given story. 

When a block of storage is requested, textw first looks to see if there is 
a free block in the front chain. If so, this block is used immediately. If there 
are no blocks in the front chain, textw looks at the oldest oops copy (the 
first block in the rear chain). If the record is old enough (24 hours), it is 
used immediately. If the oldest oops record is not old enough, textw will 
allocate a block of storage from the virgin area. If there are no virgin free 
records, textw tries to allocate another extent in the text file, thereby 
creating more virgin free records. If this fails, textw will revert to using 
oops records, even though they are not old enough. Finally, if there are no 
oops records, textw will reply to its requestor with an error that the text file 
is full and the story will not be stored. The status of the text file can be 
obtained at any time by running the program percent (see Section 76). 
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SECTION 51 


Text Holding Area 


Standard Disk File Name(s): Ssystem.vpend.f502 
Standard List Name: n/a 
Config Record Type: N/A 


Description 

The text holding area contains the text of a story while it is being edited. 
This text is written to the text file when the story is finished. Each 
vcontrol process has its own text holding area. 

The text holding area is also used for recovery purposes, vcontrol 
takes “snapshots” of the story when certain editing commands are given 
(for example, skip to front or back of a story), or when requested by the 
user with the snapshot command. If the vcontrol process were to be 
restarted (for example, after a processor failure), it can recover the user’s 
text as of the last snapshot. 

The user’s move string is also maintained in the text holding area. 
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SECTION 52 

Q-Field File 

Standard Disk File Name(s): Ssystem.q.qfield 
Standard List Name: q fields 
Config Record Type: 13 

Description 

Q-fields were set up to match all of the data types permitted in tal on the 
Tandem system. Any file that can be created can be examined and/or 
changed with the q process. This includes data types that are not sup¬ 
ported by the form generation fgen and list generation lgen processes 
(see System/55 Form and List Generation [S55-001]). 

q is an interactive process used to define and modify Q-fields. It allows 
you to obtain information from files in a general manner. You describe 
fields that indicate the format of the information and assign symbolic 
names to the fields. The information contained in the fields can be dis¬ 
played or modified at any time using a variety of techniques. 

See the Index of Record Structures (S55-007) for a thorough discussion 
of Q-fields and the q Process. 
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SECTION 53 

Q Cross-Reference File 

Standard Disk File Name(s): Ssystem.q.crossref 
Standard List Name: q xref 
Config Record Type: 14 

Description 

The Q-field cross reference file is used by q, lgen, and fgen to associ¬ 
ate a file name with structures in the Q-field file. 
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SECTION 54 

List File 

Standard Disk File Name(s): Ssystem.editor.lmsg (editorial); 

Ssystem.class, lmsg (advertising) 

Standard List Name: lists 
Config Record Type: 8 

Description 

The list file contains the information the lgen program needs for the 
user to display and edit lists. When a list is updated, both the list and 
lmsg files are updated. 

The lmsg file contains the actual list object code that is interpreted by 
the vput procedure to produce a directory on the screen. The object code 
is the result of a record created using the program lgen. This file is 
maintained by lgen. 
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SECTION 55 

Form Fiie 

Standard Disk File Name(s): Ssystem.editor.fmsg (editorial); 

Ssystem.class.fmsg (advertising) 

Standard List Name: forms 
Config Record Type: 9 

Description 

The form file contains the information the fgen program needs in order 
to display and edit forms. When a form is updated, both the form and 
fmsg files are updated. 

The fmsg file contains the actual form object code used by the vput 
and vget procedures to format and validate a form for the screen. The 
vputget procedure keeps a form cache in memory to avoid excessive disk 
i/o during form processing. This file is maintained by fgen. 
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SECTION 57 

VDT Statistics Description File 

Standard Disk File Name: SSYSTEM.SYSDATA.STATDESC 
Standard List Name: COMMANDS 
Config Record Type: N/A 

Description 

The vdt statistics description file contains records with 2 character 
command mnemonics and command descriptions for use with the vstat, 
dstat, gstat, and rgen methods of collecting and reporting vdt requests 
and response times. (See dstat, Section 68; vstat, Section 41, gstat, 
Section 19; and the System/55 Report Generation Manual (S55-013) for 
information on these processes.) 

A portion of list “commands” is illustrated in Figure 57.1. 


57.1 



VDT Statistics Description File 


Data Files 


Command Description List 
Command Description 
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0 
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8 
9 
A 
B 
C 
D 
E 
F 
G 
H 
I 
J 
K 
L 
M 
N 
0 
P 
Q 
R 
T 
U 

V 

w 

X 

Y 

z 


Proof prompt a story 
Run remote on right side 
Add Story to Combine List 
Interactive Spelling Check 
User Directory Method 0 
User Directory Method 
User Directory Method 
User Directory Method 
User Directory Method 
User Directory Method 
User Directory Method 
User Directory Method 
User Directory Method 8 
User Directory Method 9 
Acknowledge a message 
Basket/Desk List 
Create a Story 
Short Directory 
Edit 

Edit a Record 

Get a Story to Read 

History Directory 

Ignore Changes 

Justify story 

Spike (kill) a Story 

Long Directory 

Send a Message 

Edit Next Story/Record 

Output (nowait) 

Proof (nowait) 

Edit story to ’other’ side 
Return to Directory 
Send (transfer) a Story 
User Defaults 
View my Messages 
File Story (wait) 

Display Index 
Dictionary 
Sign Off 


Figure 57.1. A Portion of List “COMMANDS” 
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SECTION 58 

VDT Control File 

Standard Disk File Name: 

Standard List Name: 

Config Record Type: 

The download control* file controls the programs that are necessary for the 
vdts to run. The entries in the file determine which files are downloaded to 
the devices. 

The programs are actually downloaded by the download process. This 
process picks up the necessary files from disk and sends them to the 
proper device upon request from the device. 

The download processes ($dna, Sdnv, ,$dnf, Sdnx) are responsible for 
supplying the Initial Program Load for all external processing units con¬ 
nected to the Tandem system. These processes reference a data file 
(typically called Ssystem.sysdata.vdtctrl). The list called vdt control 
allows modification of records in this file. The fields in the vdt control 
form (Figure 58.1) and list (Figure 58.2) are explained below. 


Download Process SDNC 

TCU x Type C Number 7_ Device *_ 

File Name $SYSTEM.M68.CT1 _ 

Figure 58.1. vdt control Form for Coyote I Terminal 


process —The name of the download process to access this record. 

tcu —An x in this field indicates that the record references files to be 
downloaded to a Terminal Control Unit (tcu) or Coyote—or the rec¬ 
ord specifies the logical device (tcu or synchronous Coyote) to be 
downloaded. 


A blank indicates files to be downloaded to a vcu (used by et/ 960 
terminals) or the logical device (vcu) to be downloaded. 

type —A one character field indicating the type of download file this record 
is referencing. This field has a different meaning for vcus and tcus as 
explained below. 

TCU DEFINITIONS 


MNEMONIC 

B 

C 

D 

E 

F 

K 

M 

R 

S 

T 

Y 
Z 

V 


MEANING 

Coyote iv operating system 

Coyote i, qb or hb operating system 

synchronous Coyote operating system 

file to receive memory dump 

Coyote function file 

Coyote keyboard definition 

Coyote character matrix 

Coyote soft key object code 

Coyote soft key object code 

tcu operating system 

Coyote status indicators 

Coyote status messages 

logical device to be downloaded 
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VCU DEFINITIONS 

MNEMONIC MEANING 

c file to receive memory dump 

d vcu (et/ 960) operating system 

k et/ 960 keyboard 

l vcu loader 

m et/ 960 character matrix 

v logical device to be downloaded 


#(number)—The bit switch positions that must be set on the device for it 
to receive this download file. 

device —The name of the logical device that is to be downloaded. An 
asterisk (*) indicates all devices. An entry other than * indicates that 
this download record is for the named device only. 

file name —The Tandem file that will actually be downloaded. 



VDT Download 

Control 

File 


Process 

TCU 

Type 

# 

Device 

File name 

$DNAO 

X 

B 

5 

* 

SSYSTEM.M68.CT4 

SDNAO 

X 

c 

0 

* 

$SYSTEM.M68. CT1 

$DNAO 

X 

c 

1 

* 

SSYSTEM.M68.CTQB 

$DNA0 

X 

c 

2 

* 

SSYSTEM.M68. CTl 

$DNA0 

X 

D 

0 

* 

SSYSTEM.M68. SCT1 

SDNAO 

X 

D 

4 

* 

SSYSTEM.M68.SCT1 

SDNAO 

X 

E 

0 

* 

SSYSTEM.COYOTE.ERRCOY 

SDNAO 

X 

E 

1 

* 

SSYSTEM.COYOTE. ERRCOY 

SDNAO 

X 

F 

0 

* 

SSYSTEM.COYOTE.FUNCTION 

SDNAO 

X 

F 

2 

* 

SSYSTEM.COYOTE.FUNCTION 

SDNAO 

X 

K 

0 

* 

SSYSTEM.COYOTE.EDITDEF 

SDNAO 

X 

K 

1 

* 

SSYSTEM.COYOTE.SOFTDEF 

SDNAO 

X 

K 

2 

* 

SSYSTEM.COYOTE.EDITDEF 

SDNAO 

X 

K 

5 

* 

SSYSTEM.COYOTE.CLASSDEF 

SDNAO 

X 

M 

0 

★ 

SSYSTEM.COYOTE.EDITMAT 

SDNAO 

X 

M 

1 

* 

SSYSTEM. COYOTE.SOFTMAT 

SDNAO 

X 

M 

2 

* 

SSYSTEM.COYOTE.EDITMAT 

SDNAO 

X 

M 

5 

* 

SSYSTEM.COYOTE.CLASSMAT 

SDNAO 

X 

S 

1 

* 

SSYSTEM.COYOTE.SOFTOBJ 

SDNAO 

X 

T 

0 

* 

SSYSTEM.M68.TCU0728 

SDNAO 

X 

T 

5 

* 

SSYSTEM.M68. TCUAID 

SDNAO 

X 

V 

0 

SAO 


SDNAO 

X 

Y 

0 

* 

SSYSTEM.COYOTE.STATIND 

SDNAO 

X 

Y 

1 

* 

SSYSTEM.COYOTE.STATIND 

SDNAO 

X 

Z 

0 

* 

SSYSTEM.COYOTE.STATMSG 

SDNAO 

X 

z 

1 

* 

SSYSTEM.COYOTE.STATMSG 

SDNF1 

X 

B 

0 

* 

SSYSTEM.M68. FCT4 

SDNFl 

X 

B 

5 

* 

SSYSTEM.M68.FCT4 

SDNF1 

X 

C 

0 

ie 

SSYSTEM.M68.FCTQB 

SDNFl 

X 

C 

1 

★ 

SSYSTEM.M68.FCT1 

SDNFl 

X 

C 

4 

* 

SSYSTEM.M68.FCT1 

SDNFl 

X 

F 

0 

* 

SSYSTEM.COYOTE.FUNCTION 

SDNFl 

X 

F 

1 

* 

SSYSTEM.COYOTE.FUNCTION 

SDNFl 

X 

V 

0 

SF1 


SDNV 


C 

0 

* 

SSYSTEM.GA.CORE 

SDNV 


D 

0 

* 

SSYSTEM.GA.VRES 

SDNV 


D 

2 

* 

SSYSTEM.GA. WCU 

SDNV 


K 

0 

* 

SSYSTEM.GA.KEY 

SDNV 


L 

0 

* 

SSYSTEM.GA.LOADER 

SDNV 


M 

0 

* 

SSYSTEM.GA.MAT 


Figure 58.2. A Portion of the vdt Control File Listing 
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SECTION 59 

System Description File 

Standard Disk File Name: SSYSTEM.SYSTEM.SYSTEMS 
Standard List Name: SYSTEM DESC 
Config Record Type: N/A 

Description 

The system description file contains a record for each logical system. 
Each record contains information necessary for Sll’s software to operate 
correctly and to access other Sll logical systems over the expand network 
(see Figure 59.2). A record must exist for any logical system in order for it 
to receive/transmit messages via cmd m and to transmit and receive 
stories via cmd , t. (This is not the only data needed to utilize the network. 
See Section 108 for more information.) 


A portion of the system desc List is illustrated in Figure 59.1. 


* System Description 

Information 

Description 

Svstem 

Node 

Svs 

Type 

Config 

AAPE 

AAP 

E 

E 

SSYSTEM.SYSDATA.CONFIG 

Australian Assoc press 

AAPP 

AAP 

P 

E 

SSYSTEM.SYSDATA.CONFIG 

Australian Assoc press 

ALC 

AL 

C 

C 

SSYSTEM.ALLEN.CONFIG 

Allentown Classified 

ALE 

AL 

E 

E 

SSYSTEM.ALLEN.CONFIG 

Allentown Editorial 

ASPKC 

ASPK 

C 

C 

SSYSTEM.SYSDATA.CONFIG 

Asbury Park Classified 

ASPKE 

ASPK 

E 

E 

SSYSTEM.SYSDATA.CONFIG 

Asbury Park Editorial 

BALTC 

BALT 

C 

C 

SSYSTEM.SYSDATA.CONFIG 

BALTIMORE SUN Classified 

BESE 

BES 

E 

E 

SSYSTEM.SYSDATA.CONFIG 

BALTIMORE SUN editorial 

BESM 

BES 

M 

E 

SSYSTEM.SYSDATA.CONFIG 

Morning BALTIMORE SUN ed 

CANC 

CAN 

C 

C 

SSYSTEM.SYSDATA.CONFIG 

Canberra Classified 

CANE 

CAN 

E 

E 

SSYSTEM.SYSDATA.CONFIG 

Canberra Editorial 

CCC 

CC 

C 

C 

SSYSTEM.SYSDATA.CONFIG 

Corpus Christi Classified 

CHIC 

CHI 

C 

C 

SSYSTEM.SYSDATA.CONFIG 

Chicago Trib Classified 

CHIE 

CHI 

E 

E 

SSYSTEM.SYSDATA.CONFIG 

Chicago Trib Editorial 

CHRTE 

CHRT 

E 

E 

SSYSTEM.SYSDATA.CONFIG 

Charlotte Editorial 

CLASC 

CLAS 

C 

C 

SSYSTEM.SYSDATA.CONFIG 

Educational Advertising 

CLASE 

CLAS 

E 

E 

SSYSTEM.SYSDATA.CONFIG 

Educational Editorial 

CTEXC 

CTEX 

C 

C 

SSYSTEM.SYSDATA.CONFIG 

Houston Classified 

DETNE 

DETN 

E 

E 

SSYSTEM.SYSDATA.CONFIG 

Detroit News Editorial 

DETSE 

DETS 

E 

E 

SSYSTEM.SYSDATA.CONFIG 

Detroit News Editorial 

LATE 

LAT 

E 

E 

SSYSTEM.SYSDATA.CONFIG 

Los Angeles Times 

LAWE 

LAW 

E 

E 

SSYSTEM.SYSDATA.CONFIG 

LA Washington 


Figure 59.1. A Portion of the List “SYSTEM DESC" 
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A typical system desc form is illustrated in Figure 59.2. The fields in the 
form are explained following the example. 

Created by. on. at . 

Changed By. on. at . 

System name _ Description _ 

Network node _ System Id _ System type _ 

Filing Group _ Justify copy? _ Part/page/edition? _ 

Equal user names are not the same person? _ 

Should system default to r-1? 

Convert Dup'ed Stories? _ 

If so: Map _ 

Text _ 

If not: Copy Whole Hdr? _ 

Configuration file _ 

Receiver process _ 

Message process _ 

VCONTROL program _ 

FCONTROL program _ 

Figure 59.2. system desc Form 

created by—N ame of user who created this record 
on—D ate this record created 
at—T ime this record created 

changed by—N ame of user who last edited this record 
on — Date this record last edited 
at—T ime this record last edited 

system name—L ogical system name (see Section 3, “Naming Conven¬ 
tions”) 

description—C omment field to describe system 

net node—P hysical system (hardware configuration—see Section 3, 
“Naming Conventions”) 

system id—S ingle character identifier of logical system 

system type—S ingle character to specify vcontrol and updateh type 
(c = Advertising, e = Editorial) 

filing group—U ser must be in this filing group. (See System/55 Editorial 
Manager’s Manual, Section A-2) 

justify copy— Flag to specify justification of all copy when filed 

ppe—F lag to specify use of Part/Page/Edition in directory prompt 

equal user names are not the same person—F lag to control mes¬ 
sages to users with same names (only'friends) 

should system default to R-L—View prompts, forms, lists, and text 
right-to-left 

convert dup ed stories?—mapgen/textgen tables to convert charac¬ 
ters during transmit/receive 

map—N ame of mapgen table to use if convert dups flag is on 
text—N ame of textgen table to use if convert dups flag is on 
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copy whole hdr —Flag to specify all data in all fields of header are 
included with a transmitted story 

configuration file —Disk file name of local configuration file 
receiver process —Process name of local story/ad receiver process 

message process —Process name of local message broadcaster pro¬ 
cess 

vcontrol program — Disk file name of local vcontrol process 
fcontrol program —Disk file name of local foreign vdt control process 
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SECTION 60 

The Proof Key Record 

Standard Disk File Name(s): 

Standard List Name: 

Config Record Type: 

The Proof Key Record specifies the device and form name(s) to be used 
when a user executes a proof command. The entry in the proof field of 
the user's User Defaults determines which Proof Key Record is to be used. 
For example, if a user has printer entered in the proof field of her user 
defaults, all her proof requests will be directed to the device specified in 
the Proof Key Record with printer entered in the key field. In addition, if 
the specified device is a non-ASCii printer, this record indicates the map- 
gen format and textgen table to be used for conversion. 

To list or define Proof Key Records, type Icmdi [x] and complete the 
prompt as follows: 

List Name proof kevs Path _ Hardcopy _ 

Key ___ 

A sample Proof Key Record is illustrated in Figure 60.1 below. The fields 
in the form are explained immediately following the illustration. 


Key _ Device Name __ Access _ 

MAPGEN Format _ TEXTGEN Table _ Wrap _ 

No Conversion _ 

Default FGEN form names: 


Figure 60.1. The proof key Record 

key— A name specified in the the proof field of the User Defaults. 

device name —This may be a physical device or a name by which the 
user may find the proof in the spooler perusal process scan to review 
it before actually printing it. 

access —Access level. 

mapgen format —If this record applies to a non-ASCii printer, enter the 
name of the mapgen format to be used here. 

textgen table —If this record applies to a non-ASCii printer, enter the 
name of the textgen table to be used here. 

wrap —The permissible length of a line before wrapping takes place. 
Generally, this field is left blank (off) for line by line conversion. 

no conversion— This field is used mainly for testing. If set on, by entering 
x, textgen conversion will not be performed. This field must be off 
(blank) for non-ASCii printers. 

If no conversion is not on: and a map and text table are specified; 
proof uses the map and text table to convert the data. 

If no conversion is not on and a map is specified but no text table is 
specified, proof uses the map but does not do any character conver- 
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sion (i.e., the internal code character set is used). If the Map supplies 
control characters (e.g., return), the control characters are ignored. 

If the “no conversion” field is tagged and If no conversion is on, the 
map (if any) and the text table (if any) are both ignored. The data is 
output line-by-line in the internal code character set. 

default fgen form names —The name of the form(s), designed with 
fgen, to use for printing the header. If a single form cannot contain all 
desired fields, you may design as many as five forms, each taking up 
where its predecessor left off, to make up your proof header form. 

List the forms here, in order, proof requests each successive form 
name from vputget ($pvpt, $evpt, etc.) to output the header so that 
it appears to the user as a single form, proof performs some format¬ 
ting on the resultant string received from $pvpt so that fields which 
are not info only may be present. These form fields are useful be¬ 
cause they are fixed length. Info only fields have trailing blanks 
stripped. 
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SECTION 61 

Extract Files 

Extract files contain a subset of data from files with larger records. 
Extracts are used to reduce disk i/o and improve response times. 

Three types of extract files are used in System/55: 

1. Q-field extracts 

2. Header file extracts 

3. rgen report extracts 

These extracts are used by several system processes and utilities. The 
definition, use, and maintainence of Q-extracts and header extracts is 
explained in this section, rgen extracts are explained in Section 62. 

Q-Extract Records 

Standard Disk File Name(s): 

Standard List Name: 

Config Record Type: 

The Q-Extract File is made up of records containing an extract of the 
specified q structure. Each record contains a list of Q-fields from the 
specified structure. The record specifies the data that will be transferred to 
(extracted) a separate disk file or data area in the cpu. 

Most of these records are defined at system installation time and are 
modified infrequently. This file, and the records in it, was designed to allow 
programmers to make minor changes to programs (adding an extra field or 
an extra check) without recompiling an entire process. 

Using this extract, programs can obtain information about the data being 
processed from the Q structure of the record that is defined externally to 
the program. Control records that are subject to site-specific modification 
may be defined with these records. 

For example, the Q-extract record in Figure 61.1 is used to indicate which 
fields in the header will force rejustification of the take when they are 
changed. On an Advertising system, Q-extracts can be used to indicate 
which fields in the header will force credit checking. 
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Key JUST FIELDS Struct HEADER _ Chain to • 


Control Flag 7 

= JUST, 

6 = 

unfilm 

Comments Force 

JUST on 

header changes 

Field 

VR 

ctl 

Flags (0 - 7) 

1 OUT'DEV 


000 

X 

2 DEFAULT*STYL 


000 

X 

3 BASKET“NAME 


000 


4 DESK*NAME 


000 

X 

5 EDITION 



X 

6 PAGE 



X 

7 PART 



X 


8 _ 

9 _ 

10 _ 

11_ 

12_ 

13 _ 

14 _ 

15 _ 

16 _ 

IT_ 

18__ 

19 _ 

20 __ 

• 

Figure 61.1. Q-Extract Record 

key—A 12 character key for locating the record. 

struct—T he name of the structure to be extracted. 

chain to—T he name of other Q-extract records to look at if there are more 
than 20 fields. 

control—A string of 30 characters supplying data for specific process 
control. 

comments—A 30 character comment field. 

field—T he name of the field specified in the structure. 

vr—T wo characters for various usage. 

ctl—A byte value for controlling an individual process or operation on this 
field. 

flags—B it flags. The meaning of the flags is specific to the program that 
uses the extract. 

Defining these fields in a Q-extract record rather than hard-coding them 
into the various programs allows greater flexibility at the site. 

Header File Extracts 

Standard Disk File Name(s): Ssystem.editor.x... 

Standard List Name: n/a 

Config Record Type: 103 (classified dump file), 104 (other extract 
files) 

Header extract files contain a subset of data extracted from the take 
header. The system will automatically use extracts to display directories 
and lists when it detects that the fields requested in the directory or list are 
all contained in the extract for the specified path. When a directory is 
requested along a path that has an associated extract file defined (for 
example, path cl in Advertising or path ba in Editorial) the vdt process will 
read records from that extract file to list the directory. This improves 
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directory response time since records are read faster from the extiact file 
than from the header file. 

How Header Extracts Work 

When the system processes that use and maintain header extract rec¬ 
ords are started, they compile and store the information contained in the 
header extract definition records for each extract file defined in a configu¬ 
ration file record. Then, when an extract record must be created or updat¬ 
ed, the process uses that information to construct the record. Extract 
records are created by the header update process (cupdateh in Advertis¬ 
ing; updateh in Editorial) whenever a new take is filed away. Extracts are 
updated whenever a change is made to any field in the header record that 
is also contained in the extract. 

Advertising Header Extract Files 

In the Advertising system, header extract files are used to improve 
system performance of many advertising operations. The three major uses 
of header extracts are displaying directories of ads, performing the classi¬ 
fied dump, and improving the performance of rgen reports. Class dumps 
and rgen reports that would otherwise scan the entire header file to select 
ads can instead examine the extract records. This can reduce processing 
time from 30 minutes (when scanning the header file) to five minutes 
(when scanning the extract records). 

Advertising Header Extract Types 

There are three types of header extract files: 

1. Type a extracts include only the active classified ads in the system. 
When an ad is billed, the extract record is deleted from type a extract 
files. This type of extract is used by cdump since it only processes 
active classified ads. 

2. Type c extract includes all category classified ads in the system, both 
active and billed. 

3. Type e extract is an unstructured, entry-ordered extract. A new record 
is written to type e extract files every time a new ad is entered or an 
existing ad is changed. New records are appended to the end of the file, 
so the records are ordered by entry time. This type of extract is primarily 
used during the phase-in of a new system when hourly transfers of ads 
to another system are reguired. It is useful for this purpose since 
reports that only pick up ads entered in the last hour can remember the 
last ad record processed by saving the address of that record in a 
control file. Without this type of extract, a transfer report would need to 
read a record for every ad in the system each time it was executed, i his 
type of extract file must be purged every night by a scheduled obey 
take. 

An Example: The Active Ad Extract File 

The active ad extract file (commonly named extracto) was created for 
use primarily by the classified dump (cdump, see System 55 Advertising 
Management Manual [S55-029]). Using an extract file to select ads signifi¬ 
cantly improves performance of cdump and any other operation that would 
otherwise examine a large number of class headers. When active ad 
extracts have been defined, cdump reads those records and selects for 
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dumping those ads which meet the specified criteria. Performance is im¬ 
proved because the extract records are much smaller than the header file 
records. Since the records are in classification sequence, when a block of 
data is read from the disk many records are read at the same time (only 
one record may be read at a time from the header file). 

Defining Advertising Header Extract Records 

Each header extract must have a header extract definition record and a 
configuration fiie entry. 

The following restrictions apply to extract files: 

• If the list uses fields that are not in the extract file, the header file is used 
to obtain the directory. 

• If the directory is filtered or sorted, the extract file is not used. 

• A maximum of five extracts may be used for directories. 

• The files must be key-sequenced. 

• The primary key must be the first thing in the record. 

• The path specified in the extract definition must match a path in the 
header file. 

• The order of fields in the extract file must match the order of fields in the 
corresponding alternate key file. 

Advertising Header Extract Configuration File Entries 

Each extract file is defined in an entry in the configuration file. Record 
Type ^103 is reserved for the active classified extract file. Only one file of 
this type may be defined. Record type #104 is for all other header extract 
file entries (up to nine are allowed in classified). 


System C Record Type 103 Process type _ Record #999 

Process Name _ 

Program File Name ___ 

Primary CPU _ Alternate CPU _ Available CPUs _ 

Priority _ Alt Priority _ Threshold _ Server 

Server Class _ Reference Name _ 

Home Terminal __ Rund 

Input File Name 
Output File Name 

Parameter String extractO:cl: a _ 


Figure 61 . 2 . Configuration File Record for Extract File 

The parameter string of the configuration file record contains four pa¬ 
rameters separated by semicolons: 

1. The key to the header extract definition record (for example, ex- 
TRACTO). 

2. The path associated with the extract (optional; for example, cl). 

3. Single character extract type definition (optional, omit this parameter to 
create extracts for all header records.) 

a— only active classified ads (category c) will be extracted, 
c— all classified ads (category c) will be extracted. 
e— unstructured entry-ordered extract (limited usage). 
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Optional filter process (limited usage). A filter is allowed for each of the 
header extract files. The filter can determine whether to create an 
extract and how to compute the values of fields in the record. Filter 
processes require extra processing time and may affect system perfor¬ 
mance. Consult your Sll System Engineer regarding your specific 
needs. There may be other methods available to achieve the desired 
result. 


The Advertising Header Extract Definition Record 

The header extract definition record contains the names of fields to be 
extracted from the header and placed into an extract record when an ad is 
filed. Each header extract file must have an associated definition record 
(Figure 61.3). 


Key _ Description 

Field Names (separated by 


Field Names 


Field Names 



Figure 61.3. Header Extract Definition Record 


When the header extract definition record is completed and filed away, 
the system creates a q structure containing all of the fields listed in the 
specified order. The name of the structure will be the key to the definition 
record preceded by ext", for example ext'extracto. This structure can 
then be assigned to the associated extract file(s) by using the file com¬ 
mand of program q. 


Rules for Advertising Header Extract Definition 


1. access, basket'access, desk'access and story'number are re¬ 
quired in all header extracts. This will be verified by vputget and an 
error message given if any of these fields are not specified. Equated 
fields in a structure can be indicated by preceding the field name with 
an asterisk. For example, entry"date and entry'time actually refer to 
the same 32 bit field in the header, each field having a special edit code 
to display either the date or time. Both fields could be included in the 
extract structure by listing entry"date;*entry"time. A field preceded by 
an asterisk will be equated to the previously listed field. 



2 . 


If you wish to use an extract for long directories, text first is required. For 
long directories of aux-headers, aux'text'first and text'story'no are 
also required. 
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3. The key to an extract file must have a non-zero entry that is not the 
story'number. 

4. The class extract (record type 103) has required fields in a required 
order. Do not change or modify the required fields or cdump (class 
dump program) will not work correctly. There must never be more than 
one extract specified in the Advertising system with record type 103. 
Additional extracts are specified as record type 104. Fields required in 
the class extract are listed below: 


CLASSNAME 

CLASSSTATUS 

CLASS'SEQUENCE 

story'number 

TEXT'FIRST 

text'last 

LAST'DATE 

*LAST*T1ME 

ENTRY'DATE 

'ENTRY'TIME 

FILM'DEPTH 

FILM'WIDTH 

billing'factor 

BASKET 

CATEGORY 

just'status 

OUT'DEV 

HOLD'FLAGS‘1 

HOLD'FLAGS'2 

HOLD'FLAGS'3 

TEAR'lNDICATOR 

ad'start'date 

AD'STOP'DATE 

AD'KILLED'DATE 

ad'pub'group 

AD'START'EDITION 

ADSTOPEDITION 

AD'KILL'EDITION 

ad'days'dates'i 

SHOPSTARTDATE 

SHOP'STOP'DATE 

shop'killed'date 

SHOP PUB GROUP 

shop'start'edition 

SHOP'STOP'EDITION 

SHOPKILL'EDITION 

shop'days'DATE'1 

ACCOUNT TOTAL'PAID 

BALANCE'DUE 

ACCESS 

DESKACCESS 

BASKET'ACCESS 

ACC'TYPE 

AD'TIMES 

SHOP'TIMES 

AUTHOR 

TEARASSIGNED 

TEARVALUE 


5. When an extract is associated with a path in the header, the leading 
characters of the key in the extract will usually be the same as the key 
for the path specified in the header. The key in the extract may be 
longer than the key for the path in the header (and is usually required to 
be this way for a unique key). 

6. The key of an extract record (except class type e) must be unique 
(required for key sequenced files). This is usually done by including the 
story number as part of the key. 

7. Story number must not be referenced more than 10 times in an extract 
record (there is no reason for more than one reference). 

8. No more than 10 extracts may be defined. 

9. If an extract record is changed, the header update processes 
(cupdateh, advertising; updateh, editorial) must be stopped. If a clas¬ 
sified header extract is changed, the save processes must also be 
stopped. 

10. vcontrol and lgen allow a maximum of five extracts to be used for 
“quick” directories. If you define more than five, only the first five will 
be used. 
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Example: Extract Record for Path CL 


Key EXTRACTO Description Class header extract_ 

Field Names (separated by ' 1 ; ' 1 ) 

! CLASS'NAME; CLASS'STATUS: CLASS'SEQUENCE; STORY'NUMBER: TEXT'FIRST: TEXT*LAST: LAST'DATE; *LAST'TIME; E 

NTRY'DATE: *ENTRY~TIME: FILM'DEPTH: FILM'WIDTH: BILLING'FACTOR: BASKET; CATEGORY; JUST'STATUS; 

Field Names 

OUT'DEV; HOLD'FLAGS'l. HOLD*FLAGS'2: HOLD'FLAGS'3: TEAR'INDICATOR: AD'START'DATE; AD'STOP'DATE: AD'KILLED'DATE. 

AD'PUB GROCP: AD'START'EDITION: .tD'STOP'EDITION: AD'KILL'EDITION: AD'DAYS'DATES'1: 

Field Names 

SHOP'START'DATE: SHOP'STOP'DATE; SHOP~KILLED'DATE: SHOP'PUB'GROCP: SHOP'S! ART'EDITION: SHOP'STOP'EDITION; 

SHOP'KILL'EDITION: SHOP'DAYS'DATE'l: ACCOUNT'TOTAL'PAID: BALANCE'DUE'. 

Field Names 

AD'TIMES; SHOP'TIMES: AUTHOR: TEAR*ASSIGNED: TEAR'VALUE. FLAGS: AD'TYPE; ACKNOWLEDGE; *ACK'Q: AD'TIMES'RU 

N: AD'DAYS'RUN: AD*LAST*DATE'8 


Figure 61.4. Header Extract Record for Path cl (Classification) 




Maintaining Advertising Header Extracts 

When updating header extracts, use program vdtstats (see Section 
92) to determine whether extracts are in use, or how efficiently they are 
being used, and follow the steps outlined on the next page. 

1. Make necessary changes to the extract record and file it. Watch for 
error messages. 

2. Use q (see System/55 Index of Record Structures [S55-007]) to deter¬ 
mine the total length of the extract structure. 

3. Use the Tandem File Utility Program (fup) to determine if the record 
length is large enough for the new structure. 

4. If the structure exceeds the current record length, create a new extract 
file. (Follow the normal procedures for installing the new file.) 

5. Use the maint program extract command to rebuild extract records 
(see System/55 Editorial Manager’s Manual [S55-010], or System/55 
Advertising Management Manual (S55-029). 

6. Use lgen to rebuild all lists that reference the header file. 

7. Stop (once) all: 

a. header update processes (Seupd, Scupd) 

b. save processes (Classified only— Scsve) 

c. purge processes (Scprg, Seprg) 

d. vcontrol processes (Sf nnn). 

Deleting Advertising Extract Records 

Extract records are deleted in two ways. Type a extract records are 
deleted by cupdateh when the ad status changes from active (m or a) to 
billed b. This insures that only active ads are included in the extract file. 
The purge process deletes the records for other extract types when the 
story with which they are associated expires. 
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If for some reason it becomes necessary to rebuild the records in an 
extract file, the maint program extract command must be used (see 
System/55 Advertising Management Manual [S55-029]). 

Editorial Header Extract Files 

Editorial header extracts are path specific, that is, each extract works 
only for directories requested using the path specified in the extract (“ba,” 
for example). 

When entering fields in the extract, you must take into consideration the 
fields used in lists used by the specified path on the system. The extract 
record should contain fields that are frequently accessed via list defini¬ 
tions. These fields could make up one list, or be a part of many lists. 

A list is associated with a particular file, not a particular path. Thus, the 
same list may be used for many different paths. For example, suppose list 
stories contains fields story'name, guide, and lines and is associated 
with the header file. 

If this header file has alternate paths basket (ba), desk (de), and author 
(au), users could call a directory of the header file on any of the three paths 
using list stories. 

For example, a directory by path ba, key sports, list stories, selects 
records in the header file with sports in the basket field, then displays in 
a directory the fields of those records described by list stories: sto- 
ry~name, guide, and lines. 

Or, path de. key wire, list stories selects records in the header file with 
wire in the desk field, then displays the fields of those records described 
in list stories: story'name, guide, and lines. 

When defining extract records you should determine how often a partic¬ 
ular list is used with a particular path, and how often that path is used. 

If list stories is used 60 percent of the time users request directories on 
path ba, then the fields making up list stories may be candidates for 
inclusion in the extract definition record. 

The second criteria for determining whether the fields should be includ¬ 
ed in the extract definition record is how often a particular path is used. If a 
particular path is infrequently used, it really doesn't matter whether it uses 
the extract or not. If a path is frequently used and a particular list or lists 
are frequently used with that path, then using the extract becomes impor¬ 
tant. 

Not using the extract is not a problem if there is little use of a list (and 
therefore infrequent access to the field described by the list), and/or little 
use of a particular path. 

Every field described by all the lists being used to access the file on a 
particular path need not be included in the extract definition record. 
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Editorial Header Extract Configuration File Entries 

Use record type #104 for editorial header extract files. 


System E Record Type 104 Process type 0_ Record #999 

Process Name _ 

Program File Name SSYSTEM.EDITOR.XBASKET _ 

Primary CPU 0_ Alternate CPU 0_ Available CPUs 0_ 

Priority 0 Alt Priority 0 Threshold 0 Server 0. 

Server Class _ Reference Name _ 

Home Terminal _ Rund _ 

Input File Name ___ 

Output File Name ___ 

Parameter String basket;BA _ 


Figure 61.5. Configuration File Record for Editorial Header Extract File 


The parameter string of the configuration file record normally contains 
two parameters separated by semicolons: 

1. The key to the header extract definition record (for example, “basket”). 

2. The path associated with the extract (optional; for example, “ba”). 


The Editorial Header Extract Definition Record 


The header extract definition record contains the names of the fields to 
be extracted from the header and placed into an extract record when a 
story is filed. Each header extract file used in the system must have an 
associated definition record (Figure 61.6). 


Key _ Description 

Field Names (separated by 


Field Names 


Field Names 


Field Names 


Figure 61.6. Header Extract Definition Record 


When the header extract definition record is completed and filed away, 
the system creates a q structure containing all of the fields listed in the 
specified order. The name of the structure will be the key to the definition 
record preceded by ext', for example ext'extracto. This structure can 
then be assigned to the associated extract file(s) by using the file com¬ 


mand of program q. 


fil Q 
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Rules for Editorial Header Extract Definition 

1. access, basketaccess, desk'access and story"number are re¬ 
quired in all header extracts. This will be verified by vputget and an 
error message given if any of these fields are not specified. 

Equated fields in a structure can be indicated by preceding the field 
name with an asterisk. For example, the fields entry"date and en- 
try"time actually refer to the same 32 bit field in the header, each field 
having a special edit code to display either the date or time. Both fields 
could be included in the extract structure by listing entry"date;*en- 
try"time. A field preceded by an asterisk will be equated to the previ¬ 
ously listed field. 

2. If you wish to use an extract for long directories, text'first is required. 
For long directories of aux-headers, aux"text"first and text"story"no 
are also required. 

3. The key to an extract file must have a non-zero entry that is not the 
story"number. 

Example: Extract Record for Path BASKET 


Key BASKET _ Description Basket extract _ 

Field Names (separated by ' •; ' 1 ) 

BASKET; BASKET*SEQUENCE; STORY'NUMBER; TEXT^FIRST; STORY'NAME: GUIDE: LINES: TOPIC: KEYWORD; ENTRY^DATE; * 

ENTRY^TIME; FILM~STATUS: ACCESS; BASKETACCESS: DESK*ACCESS; DESK; AUTHOR_ 

Field Names 


Field Names 


Field Names 


Figure 61.7. Header Extract Record for Path ba (basket) 


Maintaining Editorial Header Extracts 

When updating header extracts, use program vdtstats (see Section 
92) to determine whether extracts are in use, or how efficiently they are 
being used, and follow the steps outlined below. 

1. Make necessary changes to the extract record and file it. Watch for 
error messages. 

2. Use q (see System/55 Index of Record Structures [S55-007]) to deter¬ 
mine the total length of the extract structure. 

3. Use the Tandem File Utility Program (fup) to determine if the record 
length is large enough for the new structure. 

4. If the structure exceeds the current record length, create a new extract 
file. (Follow the normal procedures for installing the new file.) 
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5. Use the maint program extract command to rebuild extract records 
(see System/55 Editorial Manager’s Manual [S55-010], or Systemi55 
Advertising Management Manual (S55--029). 

6. Use lgen to rebuild all lists that reference the header file. 

7. Stop (once) all: 

a. header update processes (Seupd, $cupd) 

b. save processes (Classified only— Scsve) 

c. purge processes (Scprg, Seprg) 

% 

d. vcontrol processes ($f nnn). 

Deleting Editorial Extract Records 

The purge process deletes the records for other extract types when the 
story with which they are associated expires. 

If for some reason it becomes necessary to rebuild the records in an 
extract file, the maint program extract command must be used (see 
System/55 Editorial Manager’s Manual [S55-01 o]). 
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SECTION 62 

RGEN Extract File 

Standard Disk File Name(s): Ssystem.rgen.extract 
Standard List Name: n/a 
Config Record Type: n/a 

Extract files are also important for increasing the efficiency and perfor¬ 
mance of rgen reports. Report processing time is significantly reduced by 
reading records from an extract rather than the header file. See “The rgen 
Extract File” for a discussion of extract files and their use with rgen 
reports. 

Many reports that are part of the daily classified operation must process 
every ad in the system. Even if only a few of the ads are selected for use in 
a report, all ads must be read in order to make the selection. When you run 
several rgen reports every day, each of which must read through every ad 
in the system, the total processing time can be substantial. For that rea¬ 
son, a special rgen header extract file is available for use by all daily batch 
reports. This file is identical in content to the active (type a) extract main¬ 
tained by cupdateh. The file is rebuilt every night after classified opera¬ 
tions have closed by copying into it all of the extracto file records. 

The rgen extract is an unstructured file; records can be blocked so that 
a single read operation from the file will obtain a large number of records. 
A given number of records from the unstructured extract can be read in 
one-fifth the time that it takes to read that number from the structured file. 

To create the file: 


FUP 

set ext 1000 

create Ssystem.rgen.extract 

exit ____ 

Figure 62.1. Creating the rgen Extract file 

The file is rebuilt once a night by an obey take scheduled by schedset 
and rsched. This take contains commands to the Tandem File Utility 
Process (fup) to purge data from the file and copy all records from the 
active extract. 

The contents of the obey take are illustrated in Figure 62.2. For more 
information on obey takes, see Section 99. 


Fl’P 

purgedata Ssystem.rgen.extract 

copy Ssystem.class.extracto. Ssystem.rgen.extract. share, recin X. recout X. blocknut Y 


Figure 62.2. Obey Take to Purge the rgen Extract File 
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Computing the values of X and Y 

The recin and recout values (x in the Figure 62.2) must be set to the q 
structure length of the extract record. (The actual record length may be 
larger to allow for the addition of fields. The Q structure length must be 
rounded up if it is odd.) 

The blockout value (y in Figure 62.2) is the number of bytes that will 
be written to the rgen extract per block of data. This value is computed by 
dividing the Q-record length (x) into 3,584 to find the number of records 
that will fit evenly into one block. That value is then multiplied by the q 
length (x) to arrive at the blockout value y. For example, if the o-structure 
length of an extract record is one hundred (100) bytes, then: 3,584 divided 
by 100 equals 35 (rounded down). The blockout factor (y) is 35 x 100 = 
3,500. 
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SECTION 63 

Introduction to Utilities 


The following sections describe utility processes. 
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Software 

Bulletin 


AUDIT PURGE Version 02(001) 

audpurge, the Audit Copy Purge Process, can either be run manually or automat¬ 
ically scheduled to delete audit copies of stories according to user-set criteria. Un¬ 
less this process is run, all audit copies of stories are maintained until the current 
version of the story is purged by the purge Process. For more information, see 
Section 28 of the system Manager’s Manual. 


1. Users can supply specific list of stories for AUDIT PURGE 

A specific list of story numbers which should be examined by audpurge can now 
be supplied in an external data file (probably built by an rgen). The new parame¬ 
ter string option below has been added to support this feature: 

[; IN (take “number file)] 

Specification of IN (take'number file) causes audit purge to examine the stories 
whose story numbers are listed in the data file. (The entries must be in binary.) 

(take'number file) can be an unstructured data file or a record number file. If the 
file is unstructured, then audit purge will read sequentially through the file, four 
bytes at a time; if the file is a record number file, then audit purge will read 
sequentially through the file, reading the first four bytes of each record. 

Note: Other rules regarding the purging of audit copies are still followed (i.e., just 
because a story is listed in the file does not mean that any audit copies of the 
listed story will be purged). 
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SECTION 64 

AUDPURGE 

Standard Disk File Name: SSYSTEM.SII.AUDPURGE 
Process Revision Level: S0178.E01.002 (001) 

Description 

audpurge, the Audit Copy Purge process, can be run manually (or 
scheduled) to delete audit copies of stories according to user-set criteria. 
Unless this process is run, all audit copies of stories are maintained until 
the current version of the story is purged by the purge process, audpurge 
can examine all stories in the database, only billed ads in a Advertising 
database, or only stories in specified baskets. 

The process signs on to the System Overseer as user “Audit Purge” and 
locks all stories for updating prior to examining them. Stories that cannot 
be locked are not examined. 

When it is started, audpurge opens the textw process to delete text 
file records; textr to read text file records, and the System Overseer 
(egod or cgod) to lock or unlock stories. 

audpurge also opens the header file and, if the header file has path ta 
defined, the alternate key file. This file is opened read-only and is used to 
obtain a list of story numbers that may point to the audit copies of the story 
being examined. 

In addition, a log file is opened to construct a process activity log. 

Processing 

For each eligible story or ad, audpurge makes a list of all of audit 
copies, chronologically, newest to oldest. The process then determines 
how many of these audit copies should be retained, if there are any excess 
audit copies, they are deleted, beginning with the oldest, and an entry is 
made in the log file showing how many audit copies were deleted and how 
many are remaining. 

Processing Criteria 

A story is deemed to be eligible for processing by audpurge if it meets 
the following criteria: 

1. It has a history. 

2. It is not being used by any other user on the system; that is, it can be 
locked for updating by user Audit Purge. 

3. The list of all auxiliary headers that point to audit copies of this story can 
be successfully read and the auxiliary headers point to fewer than 500 
unique audit copies of the story. 

4. The story has not been changed recently (the time period is controlled 
by the chng parameter of the run command). 
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5. If the billed option is used: 

a. The ad is billed as determined by the class status field. 

b. It has been assigned a bill date and has not been billed recently 
(controlled by the bill parameter of the run command). 

Determining Whether an Audit Copy Will Be Retained 

Assume that audit copies are numbered from 1 to N, newest to oldest. 

Audit copy N (and all newer ones, the previous N - 1 audit copies) is 

retained if: 

1. N is less than or equal to the minimum number of audit copies that are 
to be retained, as specified by the min parameter of the run command. 

2. N is less than or equal to the maximum number of audit copies that are 
to be retained, as specified by the max parameter of the run command, 
and the audit copy was not written recently. The time period is specified 
by the ret parameter of the run command. 

3. This audit copy is required to preserve the integrity of an auxiliary 
header. 


Execution Syntax 

The syntax of the run command for audpurge is illustrated in Figure 
64.1. 


run audpurge /(run options)/ (system name) 

t 

CHNG (change hours)] 

( 

RET (retain hours)] 

t 

BILL (billed hours)] 

t 

MIN (minimum audits)] 

[ 

MAX (maximum audits)] 

i 

BSKT ((basketl, basket2, .... basket20))] 

[ 

LOG (log file)] 

t 

IN (take'number file)] 


Figure 64.1. audpurge Run Command Syntax 


Parameters in square brackets ([ and ]) are optional. The various key¬ 
words must be specified as shown above to invoke an option (case is not 
significant), Defaults are assumed for each parameter omitted (see below). 
The order of the parameters is not significant except that the system name 
must be specified first. 

Options that specify hours are converted to dates when audpurge is 
started—they are not recomputed dynamically. 

Parameter Description 

system name —is the logical name of the system (for example, she) on 
which the program is being run. This determines which header and 
text files will be examined. 

chng —Change hours avoids examining the audit copies of stories that 
have been changed recently. If a story has been changed within the 
period specified in chng, the story is not considered (all audit copies, 
if any, are retained). This parameter defaults to 24 hours. 
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ret —Retain hours: The purpose of this parameter is to retain recently 
created audit copies of a story (up to max, see below). If the audit 
copy of the story was created within the given time-period, then the 
audit copy is retained. This parameter defaults to 168 hours (one 
week). 

bill —billed hours: The number of hours after an ad has been billed before 
its audit copies are examined. This parameter should only be used 
when audpurge is run against an advertising system. It causes 
audpurge to examine only billed ads within the system. This parame¬ 
ter defaults to zero hours. 

min —Minimum number of audits: At least this many audits will be retained 
regardless of parameters chng and ret. This parameter defaults to 2 
audit copies. 

max —Maximum number of audits: This is the maximum number of audit 
copies that will be retained regardless of the chng, ret, and min 
parameters. This parameter defaults to 5 audit copies. More than this 
number of audit copies may be retained if those audit copies are 
necessary to preserve the integrity of an auxiliary header. 

bskt —Basket list: If a basket list is specified, audpurge examines only 
those stories contained in the named baskets. 

log —Log file: This file is used to log the status of each story whose audit 
copies were successfully purged—or could not be purged. An entry is 
made in the specified log file for each story that has any audit copies 
successfully deleted, showing the name of the story, the number of 
audit copies purged, and the number of audit copies remaining. An 
error entry is made in'the log file for each story that has audit copies 
that should have been purged but could not be. The Log File defaults 
to $S.#LOG.AUDITS. 


Story '#13340 
Story 'DJ Res 
Story 'ad sys mgr 
Story '8/1 problems 
Story '#9978 
Story '#13113 
Story 'requests 
Story '#14059 
Story 'ad test 
Story 'update needs 
Story ’#13213 
Story '#4918 
Story 'j#S&TL£r 


1 Audits purged. 
5 Audits purged. 
1 Audits purged, 
3 Audits purged. 

5 Audits purged. 
1 Audits purged. 
1 Audits purged, 

6 Audits purged. 
3 Audits purged, 

1 Audits purged. 
5 Audits purged. 

2 Audits purged, 
a Audits purged, 


1 Audits remaining 
1 Audits remaining 
1 Audits remaining 
1 Audits remaining 
1 Audits remaining 
1 Audits remaining 
1 Audits remaining 
1 Audits remaining 
1 Audits remaining 
1 Audits remaining 
1 Audits remaining 
1 Audits remaining 
1 Audits remaining 


Figure 64.2. Output from audpurge Log File 


in — Specification of a file with this parameter causes audpurge to exam- 
ine the stories whose story numbers are listed in the data file (the 
entries must be in binary). The (take'number file) can be an unstruc¬ 
tured data file or a record number file. If the file is unstructured, then 
audpurge will read sequentially through the file, four bytes at a time; 
if the file is a record number file, then audpurge will read sequentially 
through the file, reading the first four bytes of each record. Note that 
other rules regarding the purging of audit copies are still followed; that 
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is, the fact that a story is listed in the file does not mean.that any of its 
audit copies will be purged. 

Examples 

The run command in Figure 64.3 causes audpurge to examine all 
stories within the database that have been changed more than twenty four 
hours ago. At least two audit copies of each story are retained. In addition, 
any audit copies made within the last week are retained up to a maximum 
of five audit copies, provided that none of the audit copies after the fifth are 
required to preserve the integrity of an auxiliary header. The activity log is 
written to $s.#log.audit. 


run sii.audpurge siie 
or 

run sii.audpurge siie;min 2;max 5;chng 24;ret 168;log Ss. #log.audit 

Figure 64.3. Running audpurge with Default Parameters 

In Figure 64.4, the run command specifies that all stories within the 
database are to be examined and all audit copies that exist are to be 
purged except for those that are necessary to preserve the integrity of an 

auxiliary header. The activity log is written to $s.#log.audit. 

___________ % 

run sii.audpurge siie;min 0;ret 0;chng 0 

Figure 64.4. Running audpurge to Purge All Audit Copies 


Figure 64.5 illustrates a typical run command for an advertising system. 
All ads that have been billed more than forty eight hours ago are examined 
and all audit copies of these ads are purged. The activity log is written to 

$S.#LOG. AUDIT. 


run sii.audpurge siie;bill 48;min 0;ret 0;chng 0 

Figure 64.5. Running audpurge to Purge All Audit Copies of Ads Billed More than 48 Hours Ago 

The run command in Figure 64.6 specifies that audpurge is to examine 
all stories within the two baskets abc and def that have been changed 
more than twenty four hours ago. At least two audit copies of each story 
are retained. In addition, any audit copies made within the last week are 
retained, up to a maximum of five audit copies, provided that none of the 
audit copies after the fifth are required to preserve the integrity of an 
auxiliary header. The activity log is written to Ss.#log.audit. 

run sii.audpurge siie;bskt (abc, def) 

Figure 64.6. Running audpurge to Examine Stories in Specific Baskets 
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SECTION 65 

B 

List Busy Users and Items 

Standard Disk File Name: SSYSTEM.SYSTEM.B 
Process Revision Level: S0050.E01.001 (016) 

Description 

B is a non-interactive utility process used to list busy system users and 
items, and to give a summary of process and server class activity, b is 
designed to be used by System Operators or computer maintenance 
personnel. Should it be necessary to kill or stop a vdt process or group of 
vdt processes, b enables the operator to determine how much disruption 
this might cause. 


Execution Syntax 

To run b, start Sll Command Interpreter and enter b in response to the 
semicolon prompt. 


;b 

Figure 65.1. Starting Process B 


When run with no parameters, b lists all users who are busy and 
indicates what they are currently reading, editing, or creating, b gives a 
summary following the list (Figure 65.2). 

; b 

Users and Items in use for Editorial 

BECKY ($F205) is updating Story 'Indy 500' 

RALPH (SF209) is reading Story 'Wall Street' 

JUDY (SF609) is updating Story '#5599' 

GLENN (SCF04) has requested APSJ (SEAJ1) to process 

Story '#102' 

211 busy item(s) 

Users and Items in use for Advertising 

STEVE (SF002) is updating Story '#31860' 

SHIRLEY (SF606) is creating Story. '#25277' 

SHARI (SF206) is reading Story '#23032' 


27 busy item(s) 



Figure 65.2. Busy Users on Editorial and Advertising Systems 


Available Commands 

Seven commands are available for use with b. Each provides different 
information. 

1. users— lists all signed-on users 

2. group— lists signed-on users in a specified vdt group. 
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3. find —lists a specified signed-on user 

4. process— lists the user signed on to a particular process 

5. summary— lists the number of users and busy items 

6. stats— lists system statistics 

7. class— summarizes system statistics by server class 

B also allows you to filter or limit a list of busy users and items by 
entering system following a command. The syntax is shown below: 

b system (system identifier) (command) 

All commands can be entered using their shortest unique abbreviation. 
Note that in Figure 65.3, b system editorial users has been shortened 
to B sy e u. 


; b__sy__e__u 

Users and Items in use for Editorial 
PURGE (SEPRG) is updating Story ’#3271’ 

STOCKS ($ESTX1 
WIRE CARBON ($SEND) 

UPI-WIRE ($WRUP) 

RANDY ($F806) 

JANE (SF103) is reading Story 'Users' 

TIM ($F304) has requested APSJ ($EAJ1) to process Story '#1069' 

250 signed on user(s); 211 busy item(s) 

Figure 65.3. Busy Users and Items in the Editorial System 


B Users:'List All Signed-On Users 

The users command provides a list of all users who are signed on and 
indicates whether they are currently reading, editing, creating, or have the 
terminal in the idle state, b gives a summary of system activity following 
the list of busy users (Figure 65.4). 




; b..user s 

Users and Items in use for Editorial 
JOANN ($F205) is updating Story 'Indy 500' 

BECKY ($F209) is reading Story 'Wall Street' 

TIM ($F304) has requested APSJ (SEAJ1) to process Story '#1069' 

250 signed on user(s); 211 busy item(s) 

Users and Items in use for Advertising 
RANDY (SF002) is updating Story '#31860' 

SHIRLEY (SF606) is creating Story '#25277' 

SHARI (SF206) is reading Story ’#23032' 

50 signed on user(s); 27 busy item(s) 

Figure 65.4. Busy Users on Editorial and Advertising Systems 
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B Group: List Signed-On Users in a VDT Group 

B may be run to list busy vdt users in a specified vdt group within a 
system. The syntax of the command is shown below: 


b group (group name) 

For example, suppose that in the Editorial system some vdts have been 
assigned to a group called “Copy." To list the busy users in the Copy 
group, enter b group copy. Figure 65.5 illustrates how the resulting listing 
might look. 


;b group, copy 

Users and Items in use from Group Copy for Editorial 
RANDY ($F213) is editing Story '#14888' 

TIM (SF707) 

GLENN ($F602) is reading Story '#16163' 

BECKY (SF005) is updating Story '#17435’ 

RALPH ($F113) is updating Story '#11461' 

Figure 65.5. Listing of Busy Users for Group “Copy” 

Note that if a nonexistent group name is specified, b does not identify it 
as such. 

B Find: Locate a Specific User 

B allows you to locate a specified user with the find command. That is, 
to determine to which system he is signed on (if any), and whether he is 
reading, editing, creating, or has the terminal in the idle state. The syntax 
of the command is shown below: 

b find (user name) 

If the user name consists of two or more words separated by spaces, 
the name must be surrounded by single quotes, as shown below: 

b find 'JOE BOB' 

In Figure 65.6, b has located user Randy. 


; b..f ind RANDY 
In Editorial 

RANDY {SF012) is updating Story '#6969' 

In Advertising 

RANDY is not signed on. ____ 

Figure 65.6. find Command to Locate User Randy 

Note that Randy is signed on to the Editorial system only. While it is rare 
that a user would be signed on to more than one system simultaneously, it 
is permitted. In that case, the information spelled out for each system 
would indicate the user, terminal id, and function being performed. For 
example, if Randy were signed on in both Editorial and Advertising, the 
find command would locate him as shown in Figure 65.7. (If a user is 
signed on to more than one vdt in one system, only one sign-on will be 
noted.) 
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If the find command is entered without specifying a user’s name, b logs 
the message “Missing user name” and lists all busy users and items as in 
Figure 65.2. 


;b find Charles 
In Editorial 

RANDY ($F012) is updating Story '#6969' 

In Advertising 

RANDY (SF702) is reading Story ’#13069’ 

Figure 65.7. find Listing for User Signed-on to Multiple Systems 

Process: List Process User 

The process command allows you to determine which user is signed 
on to a particular process (Figure 65.8). 


;b process, $F013 
In Editorial 
RALPH (SF013) 

RALPH ($F013) is updating story ’#2969’ 


Figure 65.8. b process Command 


Summary: List Summary of Busy Users 


The summary command provides a brief description of system activity. 
The names and locations of individual users are not listed (Figure 65.9). 


;b summary 

Users and Items in use 

for Editorial 


250 signed on userfs); 

211 busy item(s) 


Users and Items in use 

for Advertising 


50 signed on user(s); 

27 busy item(s) 



Figure 65.9. A Summary of Busy Users And Items 




B Stats: List Process and Server Class Statistics 


The stats command lists all processes and server classes for each 
system, the number of requests made to each process and server class, 
the total time it has taken to comply with those requests, and the average 
response time (Figure 65.10). 


The total usage figure (requests) and total time count (time) is begun at 
cold start, and can be cleared with request Segod or Scgod H4. Some 
process and server class statistics display a two-part average time. For 
example, the statistics for process Seprf (Figure 65.9) give an average of 
5.16 + 4.98. The first figure (5.16) indicates the average service time 
required for proofing a take. The second figure (4.98) is the amount of time 
a job in the process was queued before running. In the case of Seprf, it 
took an average of 5.16 seconds for each proofing to complete, and each 
job was queued approximately 4.98 seconds before being addressed. 
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;b stats 

Statistics for Editorial 

Process: $EL6 Server class: L606 

Requests: 1 Time: 6.32 Average: 6.32 + 2.54 

Process: SEPRF Server class: PROOF 

Requests: 396 Time: 2046.85 Average: 5.16 + 4.98 

Process: SESVl Server class: SAVE 

Requests: 82 Time: 1483.88 Average: 18.09 + 0.73 

Statistics for Advertising 

Process: SCAJ1 Server class: APSJ 

Requests: 3 Time: 8.84 Average: 2.94 + 0.03 

Process: $CDTA Server class: DATA 

Requests: 0 Time: 0.00 

Process: $CPRF Server class: PROOF 

Requests: 1 Time: 2.72 Average: 2.72 

Process: SCSVE server class: save 

Requests: 5 Time: 23.55 Average: 4.71 + 0.02 

Process: SCSPL Server class: SPELL 

Requests: 0 Time: 0.00 


Figure 65.10. System Process and Server Class Statistics 


B Class: Summarize Statistics by Server Class 

The class command summarizes statistics for server classes for each 
system. The display includes total usage (requests), average response 
time (average), and the time the process was queued before running 
(delay). A typical summary might appear as illustrated in Figure 65.11. 


; b..class..system e 
Summary statistics for Editorial 


CLASS 

SERVERS 

REQUESTS 

AVERAGE 

DELAY 

APSH 

1 

15 

2.75 

0. 08 

APSJ 

1 

20 

7. 55 

0. 01 

PROOF 

1 

39 

1. 54 

1. 44 

QUME 

1 

85 

6. 92 

7. 16 

QUMEH 

1 

0 



QUMEJ 

1 

103 

12.92 

0. 14 

SAVE 

2 

474 

10. 08 

0. 02 

SPELL 

1 

16 

34. 70 

0. 01 


Figure 65.11. Server Class Statistics for an Editorial System 


B Error Messages 

The following messages may be given while you are using b. Most 
messages occur immediately following the command entry that generated 
the error. 

“Fatal i/o error in (file name)”—There has been a hardware failure. Notify 
your System Manager. 

“Missing system specifier”—You have used the system command without 
specifying a system. 

“Missing user name”—You have used the find command without specify¬ 
ing a user name. 

“No startup message found”— b did not receive a startup message. Try 
again. 
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“Open failed for (filename)”—Either the file does not exist, or you do not 
have the authority to access it. 

“Unknown option specified"— b could not decipher the command you 
entered. 













